There is a difference between what is checked and what the user needs to know. The number one rule is, length is the only rule the user needs to care about.
No more multiple confusing BS rules, just a single common sense rule that is backed by actual data – see the graph in the post.
But yes, I also believe it is irresponsible to let users have a password equal to their username, or any password in the 10k most common passwords across millions of breached password lists. That’s not a rule, though, that is a check.
You’re just debating semantics about a joke I made now, which seems a bit silly no? I fail to see how to you are arbitrarily choosing to classify things as “rules” vs “checks”. I really don’t see how “Your password must contain at least 5 unique characters” (to enforce your entropy requirement) or “Your password cannot be the same as your email” is any less of a rule than “You must have at least one letter, number, and symbol”. What possible English definitions of the words “check” and “rule” definitively categorizes the first two as “checks” and the last one as a “rule”? All of them are enforced and checked at the same time and display an error to the user if broken. Maybe some of them are less likely to be broken and thus don’t need to be explicitly displayed right away, but what does that have to do with whether it’s a rule or not?
The idea is to focus on the one understandable simple practical works-in-real-life-in-all-situations rule: length. The one rule to bind them all. Users can enter (almost) anything, in proper Unicode, provided it’s long enough.
The other bits are more like genie-special-exception checks. You can’t wish for more wishes, kind of thing. It doesn’t need to be discussed up front because it should be really rare.
I’m well aware of what the point is. But we’re not talking about the point, we’re talking about a joke I made, the life of which has been completely sucked dry now lmao. I stand by the validity of the premise of the joke, for the sake of being a joke.
There was a bug in a password crypt library that when passed input with the 8th bit set on a character it would trigger a condition that would ignore some of the other characters in the password.
This was not related to Unicode, but would also effect users that submitted passwords in any non-ASCII character set.
There are some reasonable concerns around Unicode and passwords, but most of them stem from browser support. A single semantic string can be modeled in more than one way in Unicode, and so entering the same text in two browsers may not result in the same characters and therefor bytes. There are best practices that can mitigate those issues though.
Yes, the crooks have done all the hard work for you. Rumi wrote a poem about a priest who praised the thugs who beat him on the street. They reminded him that “what I want is not what they want.”
This is going to feel spammy but it’s totally related. If it’s not allowed then just delete my post.
I really have solved (at least part) of the password problem. It’ll be difficult to believe, I know. I’ve created a way for you to draw a password which in turn generates a 64 character SHA-256 hash which is different for every site. You never have to memorize a password again. The app does that for you. You draw one geometric shape on the grid and you get a password for each of your sites. You can get the free app for iOS, Android or the WinForm app or you can try the web app. You can see it and get it at my site at http://cyapass.com or just search the AppStore or Google Play and get the free app and try it. If you want to try it without installing anything you can go to : http://cyapass.com/page/CYaPass-Web-App. Nothing is posted or saved except your site keys in your localStorage for ease of use.
I hope you’ll just check it out and post back or contact me through my site even if you decide you hate it. Just try it. It’s very close to creating a random password that you don’t even know. While writing and testing the app I decided that much of what is being done with passwords (like requiring specific chars) is wrong. Thanks for your time.
I (the user) should be allowed to have my password be "abc"
why? just because! If I choose to have an unsafe password, it’s my bad and I deseve to be hacked.
So do not enforce anything. Just inform and have a checkbox saying “I confirm I want to use an insecure password” (like wordpress does during installation)
Also, do the dropbox thing. SHA the password, salt it, pepperit, bcrypt it, aes the result. Good luck trying to hack this antyime this century.
The worst password rule is the one that is never shown: the maximum character limit!
I’ve started to notice this when I started using password managers and tried to make my auto-created password extra long. Unfortunately, most authentications don’t accept more than 16 characters, some require even less. And, hardly any authentication site will tell you that beforehand (and sometimes it won’t even tell you afterwards: instead you just get “password too long” without telling you the max)
Even worse, I remember one login that does accept a longer password upon signing in, but will cut it off at 16 characters without telling me! Took me quite some time to figure that one out…
The max length should be long enough that it rarely needs to be reported! I think 100 chars is a good baseline maximum, and I think the NIST doc recommends 64.
There is a cost to hashing very long passwords where it can become a DDoS, but certainly not until 100+ chars.
I’ve considered why passwords are limited to such a short length so often, but could not come up with any good answer. A login DDOS attack never ocurred to me. But I concur that 100 chars should be sufficient.
On a different note, I’ve come up with the best password rule (apart from not using one):
The quality must be greater than X. (the site owner can choose X dependend on the security relevance of her site)
The term quality in this context refers to whatever password managers like KeePass (and some login sites) use to measure password strength. Just let the users type whatever they want - as long as the resulting password is strong enough, whether or not it adheres to any other password strength rule is irrelevant.
I have actually been thinking how terrible this situation is myself lately. As someone who doesn’t have deep crypto experience, I have a question.
I use a password hasher, where I use a not-terribly-long password plus the site’s hostname to generate a hash of arbitrary length (most of my passwords are currently 20 or 24 characters, e.g.)
What I’m wondering is, if you have a short seed word and an arbitrary hash length, does that produce sufficiently random passwords to make them as difficult to crack as user-created ones of the same length, or does that introduce an exploitable weakness?
Reason I’m asking is, could one not build an auth system that works the same way, and bake it into the client? Enter some simple string of say, 8-12 characters, with no restrictions whatsoever, and then a number from e.g. 20 to 64. To login, you then have to remember your (relatively simple) password, and the length, both of which could be used for any number of sites that work this way, because you would incorporate some unique key per site (such as the hostname). The client lib hashes all that crap and basically regenerates your password every time.
