Password security for the masses

[Wartex]

My attempt at explaining why it's important to use different and difficult passwords for different systems.

http://headsplosive.com/2012/06/password-security-hashes-and-rainbow-tables/

[free_electron]

Explain 'salting' next. Salting the hash is effective at blocking rainbow tables..

[elliott]

Explain 'salting' next. Salting the hash is effective at blocking rainbow tables..

Unless they decide to do something silly like they did with WPA and salt the hash with the ESSID.

[NiHaoMike]

Explain 'salting' next. Salting the hash is effective at blocking rainbow tables..

Unless they decide to do something silly like they did with WPA and salt the hash with the ESSID.

Changing the SSID to an uncommon one thwarts that attack.

[amspire]

My attempt at explaining why it's important to use different and difficult passwords for different systems.

http://headsplosive.com/2012/06/password-security-hashes-and-rainbow-tables/

A great explanation. You explain very well how sites should implement passwords. The really good sites will internally salt all the password hashing which makes a rainbow table useless unless the hacker knows the details of how the hashes are salted. 

Unfortunately, very many sites do not even understand the need for hashing passwords. Basically no site should ever store any password at all, which means that no secure site can ever email you your password if you forget it - the only thing they can do is to reset it to a new random password. Any site that can email you your password has all the passwords and usernames stored in a database, and when they get hacked (as happened at Sony with their Playstation logins), the hackers get everyone's login details. Almost certainly many people will use the same password on many other sites - like banks, PayPal, GMail, Facebook, etc. People love reusing their favorite passwords.

A system to "salt" or add something to your password to make it different for each site is a really good idea if you need to have passwords you can remember, but that will also be fairly secure. You just have to invent a method for generating a salt from the site name that is not at all obvious.

Say your favourite password is "aaed5ght". For Facebook, you might take the first 4 characters "face", increment each letter by one to make it "gbdf", put them in reverse alphabetical order - "gfdb" and then add this to the start of your favourite password to make it "gfdbaaed5ght" for Facebook only. If someone works out your facebook password, they still will not know any of your passwords for other sites.

I do particularly hate sites that require capitals, numbers, punctuation, etc in passwords as that just gives an illusion of security. Every site that requires this nonsense does not properly understand security. A good password is random and long, and the mix of character types ultimately hardly matters. You can have a very secure password made of just "1"s and "0"s if you like.

One of the problem with requiring numbers and punctuation in a password is that many people use Leets (or L33t) where you say replace an "e" with a "3", an "i" with a "!" , an "L" with a "1", and you end up with a supposedly secure password like "\/\/!11!am" instead of "William". Unfortunately, the hackers know all about Leeting, so it does not add anything to security at all.

Richard.

[Wartex]

A great explanation. You explain very well how sites should implement passwords. The really good sites will internally salt all the password hashing which makes a rainbow table useless unless the hacker knows the details of how the hashes are salted. 

Even if the hacker knows the salts and knows how they are applied, he now has to calculate lookups for hash(password + salt), and with salt being significantly long (I use 64 chars on my forum) this will take forever. My friend uses hash(hash(password + salt)) which makes it even more pointless of calculating.

Unfortunately, very many sites do not even understand the need for hashing passwords. Basically no site should ever store any password at all, which means that no secure site can ever email you your password if you forget it - the only thing they can do is to reset it to a new random password. Any site that can email you your password has all the passwords and usernames stored in a database, and when they get hacked (as happened at Sony with their Playstation logins), the hackers get everyone's login details. Almost certainly many people will use the same password on many other sites - like banks, PayPal, GMail, Facebook, etc. People love reusing their favorite passwords.

Newegg.com stores passwords in either plaintext or reversible encryption. Also their customer service reps can see it.

A system to "salt" or add something to your password to make it different for each site is a really good idea if you need to have passwords you can remember, but that will also be fairly secure. You just have to invent a method for generating a salt from the site name that is not at all obvious.

This is not secure, if 2 password are calculated the rest can be guessed. Salts should be random.

Say your favourite password is "aaed5ght". For Facebook, you might take the first 4 characters "face", increment each letter by one to make it "gbdf", put them in reverse alphabetical order - "gfdb" and then add this to the start of your favourite password to make it "gfdbaaed5ght" for Facebook only. If someone works out your facebook password, they still will not know any of your passwords for other sites.

This is not practical. Best passwords are long passphrases.

I do particularly hate sites that require capitals, numbers, punctuation, etc in passwords as that just gives an illusion of security. Every site that requires this nonsense does not properly understand security. A good password is random and long, and the mix of character types ultimately hardly matters. You can have a very secure password made of just "1"s and "0"s if you like.

Forced password rules are always bad. Also having a pass made out of numerals is a guarantee it's in a rainbow table.

One of the problem with requiring numbers and punctuation in a password is that many people use Leets (or L33t) where you say replace an "e" with a "3", an "i" with a "!" , an "L" with a "1", and you end up with a supposedly secure password like "\/\/!11!am" instead of "William". Unfortunately, the hackers know all about Leeting, so it does not add anything to security at all.

Richard.

Leeting adds significant iterations to dictionary attacks. Unfortunately people pay big money for cloud computing just to crack hashes so while a home PC will take many times longer to precompute leeted passes, there are existing, private tables that already have them.

[amspire]

A system to "salt" or add something to your password to make it different for each site is a really good idea if you need to have passwords you can remember, but that will also be fairly secure. You just have to invent a method for generating a salt from the site name that is not at all obvious.

This is not secure, if 2 password are calculated the rest can be guessed. Salts should be random.

It is totally secure if someone only has one of your passwords. To get two passwords, they have to hack two different sites that have your plaintext passwords. Then they have to work out how you have altered the passwords (that probably uses a method you make up that can be totally different to the example), and then they have to work out the method you use to generate the seed (which can be way harder then the method I suggested). The seed can be much longer.

Random passwords for each site is the best, but then it is impossible for you to remember them.

This was a compromise suggestion that means you have probably as close to secure as you probably need, but also you could remember the passwords for each site

Say your favourite password is "aaed5ght". For Facebook, you might take the first 4 characters "face", increment each letter by one to make it "gbdf", put them in reverse alphabetical order - "gfdb" and then add this to the start of your favourite password to make it "gfdbaaed5ght" for Facebook only. If someone works out your facebook password, they still will not know any of your passwords for other sites.

This is not practical. Best passwords are long passphrases.

Saying it is not practical with no reason doesn't make any sense to me.

"gfdbaaed5ght" is 12 characters. Even if they know I only used lowercase and numbers, a brute force attack still requires up to 30,000,000,000,000,000,000 guesses. If it is not enough for you, add a few more characters.
I cannot see any reason this is not practical, and it is far better then the typical 6-8 character non-random passwords that many people use as login passwords.

For most uses, a 10 random character password is pretty secure. It probably can be broken, but the people who can break it can probably get a warrant to access your account anyway.

I do particularly hate sites that require capitals, numbers, punctuation, etc in passwords as that just gives an illusion of security. Every site that requires this nonsense does not properly understand security. A good password is random and long, and the mix of character types ultimately hardly matters. You can have a very secure password made of just "1"s and "0"s if you like.

Forced password rules are always bad. Also having a pass made out of numerals is a guarantee it's in a rainbow table.

All passwords are made out of "0"s and "1"s - didn't you know computers store information in binary? So of course a password made out of "0"'s and "1"s can be as secure as any other password in existence - as long as you have enough "0"s and "1"s.

Numeric passwords are only vulnerable to attack if they are too short. The rule of thumb is that a password made of numerals "0" to "9" has to have about twice the characters as a password made from lower case+upper case+punctuation+numerals to get identical security.

If you are talking about the brain-dead sites that only allow an 8 character password - that is a different problem. For them, you will want to use every possible useable character to generate a password.

One of the problem with requiring numbers and punctuation in a password is that many people use Leets (or L33t) where you say replace an "e" with a "3", an "i" with a "!" , an "L" with a "1", and you end up with a supposedly secure password like "\/\/!11!am" instead of "William". Unfortunately, the hackers know all about Leeting, so it does not add anything to security at all.

Leeting adds significant iterations to dictionary attacks. Unfortunately people pay big money for cloud computing just to crack hashes so while a home PC will take many times longer to precompute leeted passes, there are existing, private tables that already have them.

The point I was trying to make is a bad password (such as a dictionary word) + leeting is far worse then a random character password. Leeting make the user, and the password check algorithm on the site think they are using a secure password, when it is in fact they have a really really bad password. When I have seen leeting used, it is usually done to a word that is a very bad password.

As much as you may hate it, people have to log into many sites, and just about everyone wants a password they can remember, as they cannot write the passwords down. How can anyone remember ten 12 character random passwords with no chance they may wake up one day, and find they have forgotten one.

If you have to write the passwords down and carry the piece of paper around with you, then you have just made a bigger security hole then everything I have suggested up to now.

There are sites like Onepass, and packages like Keypass - but you may not want to trust them.

Richard.

[_Sin]

Pretty much all your passwords, no matter how many you have and/or how difficult they are to crack or guess, are only as secure as your email. Because with access to your email, someone can just use the "I've forgotten my password" button....

[mikeselectricstuff]

Can someone please explain to me why, in the 21st century we still need "secure" passwords?
It is surely not rocket science for systems to keep password data internally secure, and have time lockouts that prevent any sort of brute-force attack?
Am I just being naive - surely system designers can't all be this incompetent? Or are they just hampered by long-standing insecurities embedded in older systems that are just too hard to change?
How hard can it be...?

[SeanB]

The problem is the spagetti code around the applications, that allow access to functions and portions of the machine that should not be exposed. Add to that state being expensive, a few bits here per connection adds up quickly if you are handling thousands of requests. The designers are under time pressure, as long as it works it ships, security testing being normally deferred for " the next time when we have a little more testing done" along with " shoot it crashed dunno why but it restarted ok"  being the first sign of a bug, but a hard to trace thing.

[amspire]

Can someone please explain to me why, in the 21st century we still need "secure" passwords?
It is surely not rocket science for systems to keep password data internally secure, and have time lockouts that prevent any sort of brute-force attack?
Am I just being naive - surely system designers can't all be this incompetent? Or are they just hampered by long-standing insecurities embedded in older systems that are just too hard to change?
How hard can it be...?

Security is very well known by the security experts, but the trouble is users always want it easier. They want something else, like your suggestion that the computer should just do the authentification for you using stored information.

For one, the expert know that for security, you cannot have a  secured password somehow safe in your computer as that is exactly what the hackers want to see.  If you secure the passwords by another password stored in the computer, that is a big vulnerability.

A truly secure password depends on there being one or two factors that only you know. The best passwords are one time passwords and once a password is used, you can never use it again. These may depend on a credit card sized display you carry that generates a new one time password every minute, and that is what you have to use to log on. This method means there is nothing stored in the computer that allows a hacker to discover the login. If a keystroke logger captures you entering the password, it doesn't matter. That password will never work again.

Also two or three factor authentication is better still so it can be something you carry (like this card), something you know (like a password), something unique to you (like a iris scan) all combined to allow a login.

Another example of where users love to demand broken security is the case of cloud storage of data. You should have it encrypted if you are storing it in the cloud. If you have secure encryption and only you have the password, then if you loose the password, there is absolutely nothing the cloud storage provider can do to allow you any access to your data - it is totally lost. Customers usually want the provider to offer some kind of password recovery, and that means they break the security of the encryption.

Security experts work on the assumption that everything about the encryption algorithm can be known, so there is no security in making the process complicated. When the algorithm is fully known, that can bust the use of lockouts (like three tries and then you have to wait 24 hours) to stop brute force attacks, as the hacker can often do the brute force work on another machine programmed with the algorithms and a piece of encrypted data, a portion os encrypted data captured in RAM, or a key captured from your computer. The experts know that a hacker may be able to access every file on the computer, every keystroke typed into the computer, and every byte of ram in the computer which may include at times complete plaintext passwords.  In spite of all this being known, it is still possible to offer truly secure encryption and logins.

That is pretty clever.

You may think "I want to protect against an external brute force attack, but I don't need to protect against someone who gets inside my computer." That is nice, but it is not true security. The moment a security expert is forced to start making arbitrary compromises like that, the security usually starts collapsing into a big insecure mess.  True security is where you trust no one except yourself, and that includes all the other companies who write software for your computer, the company that supplies the operating system - basically everyone else.

Richard.

[alm]

For one, the expert know that for security, you cannot have a  secured password somehow safe in your computer as that is exactly what the hackers want to see.  If you secure the passwords by another password stored in the computer, that is a big vulnerability.

Plenty of security experts (eg. Bruce Schneier) recommend password managers. This is the only realistic solution if you expect users to pick unique, secure passwords for the various websites they visit.

You may think "I want to protect against an external brute force attack, but I don't need to protect against someone who gets inside my computer." That is nice, but it is not true security. The moment a security expert is forced to start making arbitrary compromises like that, the security usually starts collapsing into a big insecure mess.  True security is where you trust no one except yourself, and that includes all the other companies who write software for your computer, the company that supplies the operating system - basically everyone else.

You might be referring to the "reflections on trusting trust" presentation by Ken Thompson. The gist of this talk was that an attack like this would be impossible to detect, not that it's a realistic assumption to expect a system to defend against it. If the OS, compiler or hardware is rigged, you've lost. The hardware or OS might contain all kind of advanced monitoring and phoning home capabilities. Not much you can do about it unless you build everything yourself, starting from a pile of sand (until they invent a way to introduce back doors in sand crystals).

[amspire]

For one, the expert know that for security, you cannot have a  secured password somehow safe in your computer as that is exactly what the hackers want to see.  If you secure the passwords by another password stored in the computer, that is a big vulnerability.

Plenty of security experts (eg. Bruce Schneier) recommend password managers. This is the only realistic solution if you expect users to pick unique, secure passwords for the various websites they visit.

But you still need a password to login to the password manager, and the login can be made secure with multiple factor authentication.

You may think "I want to protect against an external brute force attack, but I don't need to protect against someone who gets inside my computer." That is nice, but it is not true security. The moment a security expert is forced to start making arbitrary compromises like that, the security usually starts collapsing into a big insecure mess.  True security is where you trust no one except yourself, and that includes all the other companies who write software for your computer, the company that supplies the operating system - basically everyone else.

You might be referring to the "reflections on trusting trust" presentation by Ken Thompson. The gist of this talk was that an attack like this would be impossible to detect, not that it's a realistic assumption to expect a system to defend against it. If the OS, compiler or hardware is rigged, you've lost. The hardware or OS might contain all kind of advanced monitoring and phoning home capabilities. Not much you can do about it unless you build everything yourself, starting from a pile of sand (until they invent a way to introduce back doors in sand crystals).

You can defend against all of the above. The solutions are all known technology. The problem occurs when people who do not understand security start interfering with the security experts on the basis of the sort of assumptions you have just made.

If no one machine ever had all the information needed to break the login, then even with all the problems you mention above, the login can not be stolen.

Richard.

[alm]

You can defend against all of the above. The solutions are all known technology. The problem occurs when people who do not understand security start interfering with the security experts on the basis of the sort of assumptions you have just made.

How would you defend against the compiler in Ken Thompson's example? I believe there was one theoretical paper published a few years ago which proposed writing a very simple compiler from scratch, but this is hardly a practical solution in most cases.

If no one machine ever had all the information needed to break the login, then even with all the problems you mention above, the login can not be stolen.

Maybe not the login, if you use something like challenge response authentication (do you trust the security token manufacturer?). But whatever data you're trying to protect should be considered compromised. If the provided login authentication serves to decrypt certain information (eg. a database with credit card numbers), then the compromised hardware/software can grab this information when it's displayed or transmitted to another system. The information has to exist in unencrypted form at some point. If it just protects against access (eg. standard Windows login passwords), then it's trivial for compromised hardware/software to bypass this check.

[amspire]

You can defend against all of the above. The solutions are all known technology. The problem occurs when people who do not understand security start interfering with the security experts on the basis of the sort of assumptions you have just made.

How would you defend against the compiler in Ken Thompson's example? I believe there was one theoretical paper published a few years ago which proposed writing a very simple compiler from scratch, but this is hardly a practical solution in most cases.

I do not know Ken Thompson's work so I do not know the scenarios he was working with. Modern software practices means that the software will include a comprehensive testing suite to check the internal operation of all the routines, and this would include full tests to make sure that the encryption process is producing the correct results. For a compiler to fool the programmer, it would have to be targeted to run correctly for the testing suite, and then run differently for the final operational code. This to me sounds like a very targeted attack on a new compilation of a known an existing program. It could happen for a commercial program where everything may be compiled on one computer. It would be very hard to accomplish in open source where the programs are compiled on different compiler versions on different platforms under different operating systems. One compromised system just would not work properly with other non-compromised systems using the correct encryption with the correct secures private keys.

I think many security experts have the view that security  programs and protocols need to be open source. Closed source programs rely to an extent on obscurity for their security and obscurity is not a great form of security (especially from unhappy ex-programmers of the company).

If no one machine ever had all the information needed to break the login, then even with all the problems you mention above, the login can not be stolen.

Maybe not the login, if you use something like challenge response authentication (do you trust the security token manufacturer?). But whatever data you're trying to protect should be considered compromised. If the provided login authentication serves to decrypt certain information (eg. a database with credit card numbers), then the compromised hardware/software can grab this information when it's displayed or transmitted to another system. The information has to exist in unencrypted form at some point. If it just protects against access (eg. standard Windows login passwords), then it's trivial for compromised hardware/software to bypass this check.
[/quote]

In any two sided authentification system, it is always possible to make sure that no one computer has all the information needed to break the login process.  I will replace the word login for decryption as all secure login or data encryption processes come down to whether  one side can decrypt data sent by the other side.

If all the memory. etc was captured on one side, then any unencrypted data can of course be captured, but in a secure system, there will be insufficient information decrypt future data.

As I have already said in the "Windows 8" thread that there has to be changes to computer hardware since no present operating system can be secured, I am not going to argue that a particular PC can be made immune to a hacker taking control and seeing everything on the computer. They can also modify any program on the computer. That is a limit to all security right now, and so you have to get the best security possible given that.

So ideally, if you log into your bank and a hacker has control of your PC, they will see everything you can see, and they could even do transactions, but in a good security system, after you log off, they cannot log into your bank account again.  A fixed password login password to the bank does not rate as a fully secure login.

When you are talking about single application security, then there certainly is a major vulnerability if there is a single switch point in the program that basically enables the connection to the data. In this case, the application does have all the information needed to access all your data, so true security in a single application (including password managers) is limited if not impossible. The best security always relies on there being two or three parties and each party has part of the security information that never gets shared.

When you are talking about sites like Facebook, Gmail, etc there is no great security at all since those sites depend on the fact that all your information is fully available to Facebook and Google - that is their whole business plan. GMail makes its income by using data from your emails to select targeted advertising aimed at you. If you give those sites information that is meant to be secure, you are nuts.

Richard.

[saturation]

I think folks who have working systems that is at industry usual-customary-reasonable security won't elevate it  until they are forced to do it by law, fines or lawsuits, or included in the next vendor upgrade.

In certain industries, such as financial and now the medical field, new laws have mandated heightened security implementations, but it doesn't affect say OnlineDonutsRUs.com who then lose its customer files to a hacker with un/pw in the clear, purchase related information and their logon IP addresses.  If a user used the same un/pw it could mean a potential breach on other websites as well.

I think given those risks in the general consumer world, the best security for an individual in one they make for themselves; when the outside system is equally secure, then at worst, the users efforts just makes it doubly difficult. 

Can someone please explain to me why, in the 21st century we still need "secure" passwords?
It is surely not rocket science for systems to keep password data internally secure, and have time lockouts that prevent any sort of brute-force attack?
Am I just being naive - surely system designers can't all be this incompetent? Or are they just hampered by long-standing insecurities embedded in older systems that are just too hard to change?
How hard can it be...?

[PeteInTexas]

For one, the expert know that for security, you cannot have a  secured password somehow safe in your computer as that is exactly what the hackers want to see.  If you secure the passwords by another password stored in the computer, that is a big vulnerability.

Plenty of security experts (eg. Bruce Schneier) recommend password managers. This is the only realistic solution if you expect users to pick unique, secure passwords for the various websites they visit.

Mathematically it is all the same though, no?  If its a secure password in one site, surely its is also a secure one at another (assuming the same minimum length and allowable characters).

If people understand where the strength of passwords come from, they would demand unlimited length passwords and the ability to use all Unicode characters.  Then all they would need is one passstring.

[alm]

Mathematically it is all the same though, no?  If its a secure password in one site, surely its is also a secure one at another (assuming the same minimum length and allowable characters).

If people understand where the strength of passwords come from, they would demand unlimited length passwords and the ability to use all Unicode characters.  Then all they would need is one passstring.

The point of unique passwords is to limit the damage of a leaked password. Imagine the hypothetical scenario where your encrypted LinkedIn password was published and some idiot at LinkedIn faild to implement proper password hashing. An attacker may be able to figure out many of the passwords used by LinkedIn users. They could also have the e-mail addresses belonging to these passwords. They now can use this same password to get access to your Gmail or Hotmail account (just search for addresses ending in gmail.com/hotmail.com), which provides them with access to many other sites through 'recover your password' procedures. They could also use the same password and e-mail address to log into Paypal and perform transactions on your behalf. Hence the advice to LinkedIn users to change their password on LinkedIn and any other site where they might have used the same password. Having different passwords for all these sites would limit the damage to just your LinkedIn account.

I do not know Ken Thompson's work so I do not know the scenarios he was working with. Modern software practices means that the software will include a comprehensive testing suite to check the internal operation of all the routines, and this would include full tests to make sure that the encryption process is producing the correct results. For a compiler to fool the programmer, it would have to be targeted to run correctly for the testing suite, and then run differently for the final operational code. This to me sounds like a very targeted attack on a new compilation of a known an existing program. It could happen for a commercial program where everything may be compiled on one computer. It would be very hard to accomplish in open source where the programs are compiled on different compiler versions on different platforms under different operating systems. One compromised system just would not work properly with other non-compromised systems using the correct encryption with the correct secures private keys.

I believe the premise was that the compiler would detect if it was compiling the login program, and insert code similar to:

Code: [Select]

if ((username == 'root') && (password == 'toor')) {
    uid = 0;
    grant_access();
}
Of course it could something much more intricate than a backdoor password, like something requiring exact timing. Short of inspecting disassembly, I don't see how any automated test suite would find this. Spreading it would be an issue, although even most GCC users get their compiler from one of the popular Linux distro's (which have dedicated build farms) or from Cygwin. It shows that life would be very hard if you're unable to trust your compiler (and by extension everything the compiler depends on). One might also imagine a system management mode (invisible to the OS) process embedded in firmware that would detect GCC running and monkey patch it to do something similar.