Your Password is Too Damn Short

blog
44

How about not letting the user choose a password, a password is never sent? That’s SQRL. Your password stays on your device, you authenticate on your device, and the password is signed by your personal key.

On storing these, which is perhaps a bigger problem, throw the problem into a different space. Make all passwords stored in UTF 32 format, four bytes per character, and make sure some of the salt is in some forgotten language glyph, as well as Japanese, Chinese, Indian etc. This gives every character the possibility of being one of more than 1 million glyphs that attackers would need to try fro every character. Of course, you would do all of the same current scrypt things as well. This would make most passwords impossible to crack the hash, because the attacker would need to test UTF8 encoding, ASCII encoding, as well as possibly UTF16 in addition to UTF32 to find the correct password set.

45

Ho my god. What did I do last night ? Sorry. It was a huge pile of crap.

46

My workplace requires long passwords,so I’ve learned how to do it-- and I do it ‘by default’ when opening a new account. This got me into trouble when opening a financial account a few months ago-- a financial institution that will not be named wouldn’t let me open an account because I kept trying to use a password that was ‘too long’. So it’s not always the user’s fault.

47

This is some good information Jeff and highlights the bad practices that have become common everywhere. I’ve said it before, you don’t need a “strong” password, you only need a long password that you can remember. There’s also the practice of using “salt and pepper” when storing the passwords that I think should be standard. You have two unique strings being added onto the password before it’s hashed, one user specific and the other applied to every password. This means even if you spend a year and break one password you have to expend the same amount of effort for every other one.

Our job as programmers/software developers/architects is to hide the complexities behind all this from our users and simply tell them, please use a password that is at least 12 characters long for example. I actually make the assumption from the start that the password will be leaked/stolen/phished at some point and put safe guards in place to detect when someone logs into an account that’s not theirs. At that point 2 factor authentication kicks in to verify it is the actual user. All that being said for some sites it’s just not worth pushing any of this onto the user and just allow them to pick whatever they’d like as a password, if it’s stored properly and the system rate limits and/or locks the account down and/or kicks in 2 factor after X number of failed attempts then it’s up to the end user to choose if they’d like a secure password or a weak one.

I used to fully support just bypassing all of this and just using google/facebook etc. as an option but I’ve realized that it actually trains the user to open up that account. I know some very technical people who used google to sign in a few places and they just looked quickly to see if it was a secure connection and forgot to check the domain. They fell victim to a targeted phishing attack that gave the attacker access to “the keys to the kingdom”.

48

If the password is stored on the browser or computer, then how will people access their account from other computers? I like Internet driver licenses like Google much better, like how you set up Discourse. Also, if users want to randomly generate passwords for themselves without going to another website, they can just slam they keyboard a few times. Obviously, that wouldn’t be as secure as a real random generator, but it would work. b*(HU$*GRuewfjfhg7(*#G@rgB takes 8.47 hundred trillion trillion trillion centuries on Online Attack and 8.47 thousand trillion trillion centuries on Massive Cracking Array.

  • Also, just for fun, I put in “8.47 thousand trillion trillion centuries” which was 7.97 hundred trillion trillion trillion trillion trillion centuries on Online Attack and 7.97 thousand trillion trillion trillion trillion trillion centuries on Massive Cracking Array.
  • “7.97 thousand trillion trillion trillion trillion centuries” was 1.00 trillion trillion trillion trillion trillion trillion trillion trillion centuries on Online Attack and 10.02 trillion trillion trillion trillion trillion trillion trillion centuries on Massive Cracking Array.
  • “10.02 trillion trillion trillion trillion trillion trillion trillion centuries” was 86.89 billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Online Attack and 8.69 hundred billion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Massive Cracking Array.
  • “8.69 hundred billion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries” was 4.18 hundred billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Online Attack and 4.18 trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Massive Cracking Array.
  • “4.18 trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries” was 3.14 billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Online Attack and 31.42 billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries on Massive Cracking Array.
  • “31.42 billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries” hit the character limit.

Maybe the solution to passwords is to use arbitrarily long amounts of time?

I use spaces in my passwords because no one uses spaces in their passwords, meaning hackers don’t guess them. U6zruRWL is 70.56 centuries on Online Attack and 2.2 seconds on Massive Cracking Array, but " U6zruRWL " (two spaces added on both sides) is 1.74 hundred billion centuries on Online attack and 1.74 centuries on Massive Cracking Array. Compare that to DDU6zruRWLDD (two Ds added on both sides), which is 1.04 billion centuries on Online Attack and 1.04 centuries on Massive Cracking Array. If you can’t use spaces for some reason (I’ve heard of some sites not allowing spaces in passwords, but never actually encountered one), use non-letter characters. @@U6zruRWL@@ has the same result as " U6zruRWL ".

Practically, though pass phrases are much more secure than short randomized sequences. Personally, I use lines of codes as my passwords. My passwords are Python variable assignments (with spaces) and take hundred billion trillion trillion trillions of centuries on Online Attack and trillion trillion trillions of centuries on Massive Cracking Array.

49

I looked into making a bookmarklet that does the per-site password generation thing (hash(masterPassword, salt, domainName)), but with bookmarklets it can’t be made secure, as far as I can see, as they execute in the web page environment.

A malicious page could just hook any function you call and steal both your master password and salt. Oops.

So you need at least a Greasemonkey script or a browser add-on to make that work. While some of these do exist, they could all do with better user experience.

50

Ho my… What happened here ? :pensive:

51

I have a yahoo email account so old that its password is “0101”. I do not think it has been hacked ever… not that it would matter much though

52

I use a Qwertycard to make all my passwords. I have a different password for every site, they are all random. When I first got it, it took a little getting used to, but its great. I never forget any of my passwords, and I feel secure knowing they are long and random! (I seem to have memorised some of the passwords I now use often) https://www.qwertycards.com/images/card_front_back.png

1 Like
53

I am assuming that everyone assumes that your salt is compromised with the data breach?

Otherwise when hashing why not just use loads of different salts to make sure that the password is massive 2000+ chars.

Also why not have the hash encrypted first then so you store a hash of the encrypted string. Now to find this out you would need to breach the source code and the database server and write something to generate these encrypted string then hash them in order to find the password. Or am I missing somthing?

54

“1.35 million trillion trillion trillion trillion trillion centuries” Think I’ll be fine, thanks.

55

Wow, that would be theoretically hackable even at 1 attempt per minute or even a few hundred per day :scream:

56

OK, I have forwarded this to a friend who’s had some recent issues with his site and at the moment only allows a maximum length of 12 characters for password length.
The next question is how long should you allow passwords to be?
How big should the column be that stores the hashed password?

57

To the user that cares about security I always recommend lastpass, alphanumeric length 22 unique passwords for every website.

But for every other user that doesn’t care (all of them) passwords have been a failed experiment.

Yes, I as a web developer can protect you from you on my sites, and only my sites. But thats pointless when nearly everyone reuses their passwords.

The best security is to use a password manager. Its ok if every website does password security wrong, because when they screw up, your 22 character random garblygoop password won’t get cracked by offline bruteforce or rainbow tables, and even if they store it in plain text, its at least unique to that website.

Passwords aren’t the answer. Users of password managers aren’t really using passwords, we’re using keys. My keychain has all of my keys. I don’t know what my keys are, but I have them.
So they’re sort-of something I have, not really something I know.

Passwords ideally will go away in the future. I think they have to. They aren’t good enough of a solution. If you can remember your password, it probably isn’t a good password. A password of sufficient strength to be internet proof is effectively a key, and you won’t remember it.

58

I’m not sure I understand what your saying but I think you should consider the problem Salt is used to solve.

You don’t Salt a password to prevent it from being brute forced, the password “123456” will always be weak and easy to crack. But salt was mainely required to solve the use of rainbow tables. in the happy old days before md5 was faster to calculate than to read from disk this huge precalculated tables helped you crack almost any password imaginable, the idea was to calculate all the hashes once save them to a database and then just search for the hash in the database. Creating the initial database might have taken some time but once it created (and many people could share their CPU power to create the first table) each password crack would be almost instantaneous.

So to fight the hash table it was good practice to add a long and random salt before the password moving passwords from being 10 chars to 20-40 chars will move the password outside any possible hash table range (even with md5 it will take to long to calculate and will take too much space)

Now when salt become common many people thought they can use it to protect there users weak passwords as well, they thought that if they’ll use single salt key but keep it really safe (not in the database) they might be able to protect the passwords from being brute force.
Unfortunately this is not true for several reasons

  1. Many breaches to sites (even with SQL injection allows you to access to code and file)
  2. Even if the hacker didn’t get access to the salt its very easy to recognize weak passwords that been hashed with the same salt. weak passwords are more common than strong one (which are unique) the weaker the password the more common it is. so if all hashed with the same salt you they will have the same hash and so by analyzing the hash frequencies and little logic you can find almost all weak passwords inside a leaked database.

More than that, not only using single salt doesn’t help weak passwords it makes medium passwords more crackble. How ? you might ask we’ll since each password is salted with the same Salt if the salt is discovered now like with rainbow tables, the attacker only need to bruteforce all the options with the salt once ( like all the options with 8 chars ) and he’ll have all the passwords with 8 chars.
But if a unique Salt was used for each password even though the attacker knows all the salts. For each password with 8 chars the password will have to be bruteforced individually. and two identical passwords will still have completely different hash making the process much longer and harder (yes a few weak passwords and maybe some medium ones will be cracked but that would have been much worse otherwise)

So its better not to reinvent the wheel, with encryption, just use modern hash with built in salt and permutations and you’ll be light years ahead of many big commercial sites out there

59

Andrew I’m not sure I agree with your last part about remembering strong passwords.
I think the human brain can remember extremely long and complex passwords (and XKCD https://xkcd.com/936/ taught us that we might need to rethink password so they’ll have more entropy but easier to remember ).
But we can probably remember one two maybe three strong passwords, and that is only if we use them regularly. So as you said we need a password manager that will remember most of the passwords for us (be we still need a strong password for our password manager)

it would be great if we could live in a passwordless world, and for 99% of our services we probably don’t need a password. But in the end a strong password that you remember is probably the most secure way to keep your data private.

BTW have you seem SuperGenPass ?
www.supergenpass.com
I was using a other password managers for a while now, but this concept sounds way better (using a strong base password is a must though)

2 Likes
60

Sure we can. Every website can implement good password security. Every user can use a strong, unique password.

The experiment is only happening because, if everything goes perfectly, security is achieved!

But the results are in. People don’t. Websites don’t.

I’m looking at this as a student of history. Indeed it would be great if we could live in a passwordless world. That is a very real and likely possibility.

In 200 years will people still be fumbling around with passwords? When the more time that passes, the more predictable the passwords become, its pointless.

The concept providing a secret in order to authenticate, thats not going away. But the human element in creating and remembering that key, that will definitely go away.

I know its hard to imagine it right now, its hard to escape our current reality, but if there is a more convenient way to authenticate that is also more secure, it will be done.

Another thing that will probably change is every website authenticating you. Its not really the job of a website to authenticate you.

When something like OpenID connect gets its shit together and becomes effortless to implement, why would I ever opt to handle the authentication of some random people logging in to comment on my blog article?

If I’m a security hobbyist, alright. Assume my blog is about cooking recipes though. I just write posts about food. I don’t care how you authenticate, and I don’t want to fool around with managing your password recovery workflow or be responsible for any of that.

You see what I mean by it not being a website’s responsibility to authenticate you? So many websites do it wrong, that I don’t think the answer is to educate all of the different websites how to do it right. Their website isn’t about ‘how to correctly authenticate’. For most websites out there, the ideal solution is to not handle authentication.

61

What do you think of http://pwapp.io/ @codinghorror?

The idea is that you can easily create complex and unique passwords for each site (40 characters long). You never need to store them, as there is always the site of the iOS app that generates the same output for you.

63

I once was asked at a job interview as web developer:

-How would you store a password in the database?

-Depends on how much we care. If the app is just a blog, or a forum just encrypting the password with a salt should be enough.

-So, let’s say you wanted to make the login for a bank account, what would you do?

-I would still not care much about passwords since there is no way we can make them secure enough. Enforcing a long password would only make the user stick it on his monitor with a post-it note, and short passwords can get cracked. If I could, I would design a system that uses a dongle that generates numbers for 2 step authentication.

-But what if the battery of the dongle dies?

-Hey, you got to weight things. What’s more important here, security or convenience?

Forgot where I was going with this, but I didn’t get the job. Oh well!

1 Like
65

Perhaps it’s already common knowledge about the XKCD Password comic http://xkcd.com/936/ - but still given that the same passwords are used on here as his comic you should respect his Creative Commons attribution license and give a nod to the article. Also one of the whole points of the XKCD password comic is to use spaces as well, so it should be: correct horse battery staple. For companies that don’t allow spaces (i.e. Microsoft Windows 8 accounts) just use hyphens instead.