Computer Science vs. Human Engineering in security

[SJ Zero]

Today I got an e-mail from the company IS department, which got me to thinking about the trade-offs between Computer Science vs. Human Engineering.

We're moving to the latest and greatest security through bravado campaign, the "secure password". It's got to be longer than a baby's arm, and utilize no fewer than 17 alphabets, of which at least two must be from antiquity.

Now I understand why they're doing this. More complicated passwords mean you're better protected from basic attacks. You can't use a dictionary attack to figure out MonesterITIS41(not my password), and a brute force attack will be made much more difficult by the increased number of characters a probable hit must contain(from 26 to 62 if you only require a-z, A-Z, and 0-9).

My problem is with the human element becoming much less secure when the theoretical digital element becomes much more secure.

For example, I've only really got one truly secure password using all the criteria that are usually asked. I can't remember any more than that. Thus, it's likely that I'll use the same password for the launch codes to the space shuttle self destruct codes as I'll use for my hotmail account if they need all these complications. Only one password means your security is only as secure as the least secure system.

I'm one of the smarter people, too! There are PLENTY of people who have their password taped to their monitor, or written on a piece of paper taped to the "hidden" place of the little sliding board in their desk as it is, making the passwords six times more complicated is only going to increase that. "Hidden" passwords mean anyone off the street can break into a system with rudimentary physical access.

So can I get some CompSci security nerds to weigh in? Which is better in practice? Does the human element end up crippling good security?

[Alias]

imo, we're getting to the stage where human frailties are holding everything back; we could fly really fast but the geforce would kill us; we could be much more productive if it weren't for the need of sleep and food etc.

Computers do math faster - the only reason we dont know more is becasue we cant think fast enough to figure it all out.

Humans are now the weaker link

[Cynical Idealist]

If you haven't already, take a look at "The Art of Deception". Its kind of scary how well social engineering works.

[Marz]

I tend to use relatively simple passwords except for my computer, which has an 11 character truly random alphanumeric string I've memorized; and encryption, for which I use a 25 character semi-random alphanumeric string. I have paranoia issues.

[Alias]

i have secure passwords on things that make me liable; work, online banking, uni applications ebay etc

and the other stuff (email, fora) i just use the same one.

[Berengal]

Due to having to change my work password every once in a while, and not being able to use the five last used passwords, I'm now up to... six passwords which I use everywhere. They're all relatively secure, being of at least 12 characters each and consisting of uppercase, lowercase, digits and non-alphanumeric characters. If you ever saw them written out, however, they'd certainly wouldn't be random. It's enough to stop brute-forcing or a dictionary attack, of that I'm sure, but someone with extremely good knowledge of how my head worked would be able to figure them out.

Also, once, at work, my user account was locked out for some stupid reason, so one of my coworkers shared her password with me so I could get any work done. Incidentally that day we had to change passwords. She delayed it until after I had gone home, so that when I came the next day the password was changed. My account was still locked out (we've got lazy sysadmins), I was early, and thus I couldn't get any work done. Except that I managed to guess my coworker's new password in two tries. When your previous password was the name of one of the two people you never shut up about (husband and daughter), I'd be willing to put money on your new one being the name of the other person.

Humans certainly are the weakest link in several setups. I think a better password policy would be not to force the users to change their passwords, but to force them to use a really secure password. It's possible to memorize a 25 character long random string and have that as your master password, and it's reasonably secure (very unlikely to be cracked unless you give it away). It's much harder to memorize a new 25 character long random string every month for every system you're a privileged member of, even though it's more secure that way. It's also much more secure, and possibly easier, than to memorize a new "easy" password every month.

[Xanthir]

I forced myself to memorize a single very long (62 characters) randomly generated password consisting of upper and lower case letters and digits. This is the password to my encrypted password file, which I have stored all over the place to ensure appropriate backups.

Thus, I only have to memorize a handful of passwords to let me get *into* a computer system. Once I'm there, I can just download my password file, decrypt it, and immediately have access to all my other passwords, which are themselves randomly generated and very strong. I don't even care about "you must change your password" requirements, because all I do is update my file and distribute it among my backups again.

Having a password file is basically a requirement for my job, anyway (I manage all of the sites that my company uses on a daily basis); I've just made this more secure than my boss' method (put them all in a notebook that he carries with him at all times) and coopted it for my own uses.

[Tac-Tics]

I ran into a service the other day (ComED's bill pay system, btw) where your password is restricted to 6 to 8 characters. I'm almost throwing a shitfit just thinking about how impossibly retarded that policy is. All my strongest passwords, the ones I use to protect my money online, are much longer than 8 characters. Why the fuck should they force me to use a less secure password? Add to the fact that it's not a usual password I use, so I'm going to forget it more often.

[Ended]

Similar to Xanthir, I use KeePass to store my passwords encrypted. This allows me to use a different, randomly generated, arbitrarily long password for each of my accounts, and only have to remember the KeePass database password (plus my computer login).

I prefer using a dedicated piece of software like KeePass for this purpose, rather than an encrypted password file, since it avoids security issues like Windows automatically caching files to disk or storing passwords unencrypted in memory.

[Xanthir]

I'm honestly not concerned about those sorts of things. I simply don't have the discipline to defend against a dedicated attacker with access to my personal computers. I'm increasing my security against remote attackers, which is what's important to me.

I also have an inherent distrust of databases. ^_^ Too easy for them to corrupt. An encrypted .txt file only has one failure point - the encryption scheme itself.

[Marz]

I'm honestly not concerned about those sorts of things. I simply don't have the discipline to defend against a dedicated attacker with access to my personal computers. I'm increasing my security against remote attackers, which is what's important to me.

Well, even OpenBSD say that once someone has physical access to your computer, it's basically open, unless heavily encrypted.

[headprogrammingczar]

I'm honestly not concerned about those sorts of things. I simply don't have the discipline to defend against a dedicated attacker with access to my personal computers. I'm increasing my security against remote attackers, which is what's important to me.

Well, even OpenBSD say that once someone has physical access to your computer, it's basically open, unless heavily encrypted.

Especially if it is Windows. Then all you need to crack it is a Linux Live CD.

[Ended]

I also have an inherent distrust of databases. ^_^ Too easy for them to corrupt. An encrypted .txt file only has one failure point - the encryption scheme itself.

True; I guess I just like the convenience of a database though.

[Savara]

What is wrong with writing down a very long & un-memorisable password & then keeping it as safely as you would an item of similar value to that which the password protects? I.E. keeping it in your wallet - surely you value your debit / credit cards, driver's licence & cash on a par with your user account / email?

[Berengal]

You can't memorize your credit card or drivers license. Writing your password down provides an unnecessary point of insecurity. If you forget it, you're locked out of the system. If you misplace your written password, not only are you locked out, but others might get access too.

[SJ Zero]

If you haven't already, take a look at "The Art of Deception". Its kind of scary how well social engineering works.

I'll have to read it. Then I can hack the world (and I don't mean computer systems).

These aren't the droids you're looking for.

[Strilanc]

I ran into a service the other day (ComED's bill pay system, btw) where your password is restricted to 6 to 8 characters. I'm almost throwing a shitfit just thinking about how impossibly retarded that policy is. All my strongest passwords, the ones I use to protect my money online, are much longer than 8 characters. Why the fuck should they force me to use a less secure password? Add to the fact that it's not a usual password I use, so I'm going to forget it more often.

That's a huge no-no. Not only does it make rainbow tables all the more effective, it means they're storing your password in plaintext. Plaintext passwords should *never* be leaving your machine!

[Marz]

That's a huge no-no. Not only does it make rainbow tables all the more effective, it means they're storing your password in plaintext. Plaintext passwords should *never* be leaving your machine!

When someone hacked into Bill O'Reilly's user database, the first thing I noticed was that all the passwords were stored in plaintext. It is absolutely ridiculous leaving it like that; MD5ing it is simple, and very effective.

[Strilanc]

That's a huge no-no. Not only does it make rainbow tables all the more effective, it means they're storing your password in plaintext. Plaintext passwords should *never* be leaving your machine!

When someone hacked into Bill O'Reilly's user database, the first thing I noticed was that all the passwords were stored in plaintext. It is absolutely ridiculous leaving it like that; MD5ing it is simple, and very effective.

The password shouldn't be transmitted over the network at all. The remote host should not learn your password at any point. They should be using password verifiers.

[Marz]

The password shouldn't be transmitted over the network at all. The remote host should not learn your password at any point. They should be using password verifiers.

I can't see a way in-browser to MD5 a password before it is transmitted, without using Javascript, meaning it would have to be sent once, and then hashed. I might be wrong, though.

[Xanthir]

Nod. Strilanc, you're misunderstanding how browsers work. Unless you intercept the form submission with javascript and prehash it, your plaintext password *will* be sent to the host. If you're using https it gets encrypted before going, but then it's decrypted on the host's side and they see the plaintext password again. (If you *do* intercept and prehash, what do you do for users who have javascript turned off?)

The important thing to do is make sure that the plaintext password is never *stored*. You hash it before it hits the database, and then anytime someone logs in, just hash their provided password and check it against the stored hash.

[Strilanc]

I understand that the password is usually transmitted. I'm saying that's absolutely the wrong way to do it. I should be able to use the same password on multiple sites by the same company without them being able to realize this, and a sysadmin for a site watching a decrypted packet trace shouldn't be able to learn my password and log in to my account later that day from his house.

It's absolutely possible to do this. Blizzard does it for Battle.net; the server never learns your password.

SRP: secure remote password protocol
http://en.wikipedia.org/wiki/Secure_rem ... d_protocol

[Berengal]

Battle.net isn't a browser and websites use http, not srp.

[SJ Zero]

I'm reminded of the gzip compression automatically built into web servers and web browsers in this discussion. Wouldn't it be entirely possible for a standard password sending method to be created, which would let a browser send an identification code securely without sending plaintext in any circumstances?

[Strilanc]

Battle.net isn't a browser and websites use http, not srp.

That feels a bit like a knee-jerk respone.

You don't have to implement SRP in the browser, although that would really be ideal. The point is not whether or not it's easy to do it. The point is that it should be done.

[Xanthir]

In Blizzard's case, it's possible because they have completely control over the internet access. They get to decide exactly what information to get from you, what to do with it, and what to send to the server all on the client side.

Browsers don't work like that. You *can* use javascript on the clientside to intercept logins and hash passwords before sending them onward, but that *only* works if you can *guarantee* that the user will have javascript active. In general you cannot, and so in general this is not possible to do.

Berengal's response was perfectly accurate.

[Strilanc]

In Blizzard's case, it's possible because they have completely control over the internet access. They get to decide exactly what information to get from you, what to do with it, and what to send to the server all on the client side.

Browsers don't work like that. You *can* use javascript on the clientside to intercept logins and hash passwords before sending them onward, but that *only* works if you can *guarantee* that the user will have javascript active. In general you cannot, and so in general this is not possible to do.

Berengal's response was perfectly accurate.

I don't really want to get into a "can it be done?" debate. I'm saying it *should* be done. Browsers should implement the ability to do it, and websites should use javascript to do it and display visible warnings that they are downgrading to SSL password transfer if javascript is disabled [or whatever].

[Marz]

I should be able to use the same password on multiple sites by the same company without them being able to realize this

I believe this is impossible even theoretically, as the same string hashed by the same algorithm must be identical in order for hashing to work.

[Strilanc]

I should be able to use the same password on multiple sites by the same company without them being able to realize this

I believe this is impossible even theoretically, as the same string hashed by the same algorithm must be identical in order for hashing to work.

You just use a salt [the salt is constant and bound to the account when it is created].

[Marz]

I should be able to use the same password on multiple sites by the same company without them being able to realize this

I believe this is impossible even theoretically, as the same string hashed by the same algorithm must be identical in order for hashing to work.

You just use a salt [the salt is constant and bound to the account when it is created].

But surely the company would know the salt?

[Strilanc]

I should be able to use the same password on multiple sites by the same company without them being able to realize this

I believe this is impossible even theoretically, as the same string hashed by the same algorithm must be identical in order for hashing to work.

You just use a salt [the salt is constant and bound to the account when it is created].

But surely the company would know the salt?

Yes. But the salt value and other values don't necessarily tell you the password.

[Marz]

Yes. But the salt value and other values don't necessarily tell you the password.

Ah, I suppose if the company just knew the hash and the salt, they wouldn't be able to determine whether the hash with a different salt would be equal to a different hash. Fair enough. However, changing our entire internet experience to use SRP instead of HTTP would still be rather difficult, in practice, and there would of course be many browsers which would not support SRP, making life difficult for web developers...

[Xanthir]

Nah, you can simulate it with a javascript library according to Wikipedia.

The issue, as I noted, is just that it's thus only usable if the user has javascript enabled.

[headprogrammingczar]

But would the rest of the website work without Javascript too?
From the sound of it, this is a smaller part of a bigger website, which would be using a much more ambitious system to transfer information (see: online payment). If you don't want to use JavaScript but have your encryption too, https might work. As for the human element, I am a proponent of the "no limits" password. If I want my password to be "penis", I can, and no one will want to guess that password. A particularly elegant solution is to have a blank password. No one checks to see if empty passwords work, because they never do.

[Berengal]

No one checks to see if empty passwords work, because they never do.

Actually, that's the first password I check whenever I'm trying to guess someone's password, even when the system nominally doesn't let you set an empty one. I've found places where an empty password always worked.

[Cynical Idealist]

If you haven't already, take a look at "The Art of Deception". Its kind of scary how well social engineering works.

I'll have to read it. Then I can hack the world (and I don't mean computer systems).

These aren't the droids you're looking for.

The book is more about how to prevent social engineering attacks, not teaching you how to do them. Then again, there are plenty of examples along with explanations of why they worked in the first part of the book, so you could probably learn something from it.

[Xanthir]

But would the rest of the website work without Javascript too?
From the sound of it, this is a smaller part of a bigger website, which would be using a much more ambitious system to transfer information (see: online payment). If you don't want to use JavaScript but have your encryption too, https might work.

No reason why it shouldn't. Note that this technique is useful *only* for passwords and similar information, where you really don't care what the information is, but rather only care that what's stored in the db and what's provided by the user reliably match in some way when they're supposed to (and reliably don't match when they're not supposed to). Online payments and such require the server to actually know what the information you're sending them is, and so you would use normal encryption to prevent eavesdropping there.

As for the human element, I am a proponent of the "no limits" password. If I want my password to be "penis", I can, and no one will want to guess that password. A particularly elegant solution is to have a blank password. No one checks to see if empty passwords work, because they never do.

"penis" is a simple dictionary word, and you can be assured that it's on the shortlist of dictionary bruteforcers. Blank passwords are literally the very first thing you should check, because many systems set themselves up with blank passwords by default, expecting you to change them immediately after installation. Many people never do. You fail at thee human element. T_T

[colonelxc]

One interesting thing in password security is the evolution of algorithms used to hash passwords. Most common on linux systems these days is the FreeBSD-MD5, which at a very simple level, is regular md5 repeated a thousand times. Does this make it any more cryptographically secure? No. What it does is drastically increase the amount of time it takes to generate a password hash. While this time is still insignificant when you're logging into the system (less than a thousandth of a second), it still takes many times longer than straight md5, meaning a brute forcer will be many times slower.

Now we're seeing the integration of the Blowfish algorithm, which is another factor of 10 slower. Again, still insignificant to the user logging in, but it means that an 8 character password with letters, numbers, and symbols will be secure from normal brute forcing. The key is to force an attacker to brute force the solution. No words, no names.

Now with that taken out of the way, the human becomes the weakest link. Crack all the weak passwords (short, or wordlist ones), and then go after the actual people for the rest

[icanus]

A method I've used in the past (though for the most part I'm as guilty as most people of just choosing something easy to remember and therefore to deduce if you know enough about me) is to forego memorizing the password entirely, and instead memorize the method for generating the password -

for example, the last character of first line of every third page of the 2004 Hyperion edition of Le Morte D'Arthur, staring at page 8, for 12 digits gives me: at.:rynflr-,

The example is probably more convoluted than it needs to be and requires having the book to hand, though it would be possible to come up with a method that didn't - (second, & third letters of family members names, followed by their year of birth for five different family members, arranged in order of height ), but the overall method seems to allow for a strong password with fairly easy memorization, removing the risk of me writing it down and leaving it next to my computer. I've therefore concluded that there must be some massive flaw that I'm not seeing.

Downside is that it can take a minute or two to figure out the password afresh each time, though once I've typed any string < ~20 characters a dozen times I'll probably remember it for the next few months.

[sakeniwefu]

Well, even OpenBSD say that once someone has physical access to your computer, it's basically open, unless heavily encrypted.

You didn't get that quote right. The last word in that sentence is "open". No amount of encryption can help if *you* can access your own data. An attacker with physical access can set up cams, keyloggers(in the actual keyboard), radio receivers if you are using a wireless keyboard(you shouldn't), and many other things.
Physical access==Game Over.
Also the correct way if you are going to attempt Social Engineering is starting with Social Engineering and *then* trying to brute-force the passwords as the latter method is less likely to work and will hopefully set the security staff on full alert mode as soon as they see a few millions of failed login attempts. Even before brute-forcing you should be trying to exploit faults in the software to try and set up some software keyloggers. Brute-forcing is only the last resort. Even in encryption the process is:

• Try to get the plaintext
• Try to get the key
• hope they are using a broken algorithm
• brute-force.