I think that 15k words is very similar to what a 10 year old child knows and does not require ecumenical-virology-assuage-malefactor
The problem is that nobody (OK, almost nobody - I am sure there is someone somewhere) will truly pick even close to randomly multiple characters from a 94 character set. We fool ourselves into thinking we’re random, but we’re not. If you let a machine pick those random characters, then it works great - like the email password system I mentioned above which gives 3 options - and the random gibberish style has the shortest string because that is good enough (longer needed for random alpha, and much longer needed for the random word method).
1 Like
No, I am not. If I (or any of us) was assuming 4 words making 25 characters the math would be 94^25 not 15000^4.
And the article you link and cite is wrong — ironically for the same reason it is trying to say the XKCD method is wrong. It is trying to have it’s cake and eat it too. Either both methods use the full range (or characters or dictionary words) or both don’t. If you give one method credit for using a fully random generated set, you have to give the other method that benefit in your math too. You can’t assume users will pick truly random characters from a 94 character set and also assume they will use a minimal set of words or vise versa. Either you help them generate random values or you don’t, but you can’t compare methods by mixing and matching scenario parameters. If you are going to discredit the word method by saying people will pick from a minimal subset of their vocabulary then you also need to assume they will pick “random” letters and symbols with a much lower than random frequency (demonstrably true). The substitution methods we (and XKCD) are advocating against only makes this tendency worse.
As it related to this site the point is that proper salting and hashing combined with some basic precautions like rejecting passwords with demonstrably low entropy will result in a reasonably secure database. Databases get compromised when they don’t do one or more basic things right, not so much when they do.
5 Likes
It’s probably also worth implementing a fairly easy API call to Have I Been Pwned’s list of Pwned Passwords to reject passwords that frequently show up in breaches. The API uses k-anonymity (check the post for the details), so the specific password being tested is not exposed beyond the client-side JS that tests it.
2 Likes
Ether you’re not actually talking about XKCD style, or I’ll have to disagree.
The XKCD method specifically tells people to use easy to remember words. In other words, it specifically tells people to use only the most obvious “characters”.
The equivalent on the “classic” side would be to specifically tell people to use things like “Password1$”.
IF you use truly random words (like the example given “ecumenical-virology-assuage-malefactor”), THEN it’s more secure. But then you go against what the XKCD method says.
Also you’d have to use some verified generator for those phrases. But at that point you’re talking about power users. I’d wager there’s not many users who go as far as using a strong, verified random generator for passwords… but then restrict it to existing words only.
I don’t know if getting bogged down in this discussion is worth it though. It would be more convincing if you just tell me what your practical idea for a password form is, to make all users use this? Because I still have no idea what you actually want to do.
1 Like
Okay, this discussion isn’t being productive any more - time to leave it there. How exactly we do password authentication will be a technical decision made during development; as long as it’s secure, it doesn’t matter exactly what method we use. Further comments on the proposed database design at the top of this thread can continue here.
9 Likes
Reinventing the wheel when it comes to auth/credential management these days is not a great idea.
For ASP NET Core, there’s Identity, IdentityServer and OpenIddict to start with (at least that I’m aware of), all of them solid offerings. I recommend we build upon one of these.
Edit: further discussion at What kind of authorization framework/library should we use?.
2 Likes
Just an ordinary lowly user here. You experts can decide how to implement security, but I’ll tell you what I want the user experience to be.
I’m really totally fed up sick and tired of web sites that take themselves too seriously and try to be too nanny-ish with security. Just let me have a user name and password with no third party site required. How secure that is is my business. You’re not my bank or holding the keys to Fort Knox. My security on your site isn’t that important to me.
Let me use whatever I want as a password, limited only perhaps by minimum length. Requiring me to create a password with a special character, a number, an upper case letter, a lower case letter, and two partridges in a pear tree actually makes it less secure. I have a mental means of generating passwords that works nicely (and no, they are not common words). If you force something obscure on me, I’ll need to write it down, making it less secure in the end.
A simple user name and passwords needs to get me in no matter where I am and on what machine. You can send a one-time key to verify my email when I sign up, but never again after that. I may not always be able to receive email at any specific address if I’m traveling, or even at a different machine in a different building.
I will forget that you did some fancy authentication on a particular machine. Then when I’m in the public library in Flagstaff Arizona, I can’t log in because I don’t have a machine with me (else I wouldn’t be using the library computers) and have no way to receive a one-time key because the email address I happen to use when I signed up can only be received at work 2000 miles away. This has actually happened. Don’t be that site.
I really don’t want to give you any details of my cell phone. Google already knows more about me than I like. You making that worse would be a show stopper. I sign up on web sites that require that sort of authentication only if I really need the service (like some government functions). You’re not that important. If you make me give information to Google or some other third party, it ain’t gonna happen. I’ll live without your service.
7 Likes
Absolutely!
I’ve made that point repeatedly, and it benefits both:
- The user - not having information about multiple systems stored/linked to one unknown/untrusted entity) and
- The system - not being dependent upon a 3rd-party site that if it goes down (totally beyond our control - and not just hardware failures but also "xyz 3rd-party site has now decided that they don’t like Codidact for some
political correctnessperceived wrongdoingsany reason.
Actually, besides minimum length, a reasonable short check against “extremely common passwords” is not unreasonable. Plus it has been discussed both here and on SE that “gibberish password requirements” do not actually add much entropy, aside from the problems you already (correctly) described from the user standpoint.
What I do suggest is a password strength meter. This is a simple enough widget (ideally a client-side library - no point in sending partial passwords back & forth to test them - that doesn’t help security!) that comes up with a Very Weak/Weak/OK/Strong/Very Strong rating based on the combination of length, relative randomness of characters, etc. Done well it is not very intrusive and set at a low setting (given the relatively low importance of this type of site vs. banking, etc.) - e.g., don’t allow “Very Weak” but allow anything else - it can be very helpful. The nice thing is that if you have a favorite gibberish password it will likely pass the test due to randomness of characters, and if you have your a favorite “lots of words strung together” password it will pass the test due to length.
Actually, that is a must to prevent spam users. It provides a small but useful bump as it:
- Helps make sure there is a real person (harder, though nothing impossible these days, for a robot process to attempt to login, setup an account and click on the right link in a received email to finish the process) without a lot of work involved for the real person.
- Makes sure that recovery via email is possible because, at least as of the initial registration time, the email address is “good”. Otherwise an innocent typo would mean a forgot-password user would have no easy way to get in. Unless we go down the insecure security questions route…ughh.
- Provides plausible authorization (opt-in) under CAN-SPAM and similar laws that the owner of the email address consents to emails from Codidact in the future.
But the “you recently signed on from an unusual location” emails actually do very little good. I can give you plenty of anecdotes but the bottom line is that while they are often valid, they are usually ignored and therefore do little good.
I agree this is a problem too. Not for me, but for plenty of my customers. The solution, not MVP, is to provide optional two factor authentication. That is what we all should be heading towards (I gave a speech on this topic at Toastmasters this week) but which most of us (myself included) don’t use as much as we should. Two factor authentication, letting users decide whether they want it and how they want to get it (App vs. token vs. text message) lets the security conscious (whether by nature, by profession or because they are moderators and really worried that someone will get in to their account and do stuff) have top-level security while letting others (who want more casual anywhere/anytime access) have that. But NOT MVP.
5 Likes
OK, but make it advisory only. I don’t mind you telling me how secure or not my password is, and even giving me advice on how to make it better. In the end though, you should accept whatever I decide.
That said, I’m not going to use “Password123” as a password, but if someone really wants to despite the warnings, that should be their call.
Otherwise I’m totally on board with everything else you said.
4 Likes
A too weak password is not only a risk for you, but also a risk for the site: Users over time gain privileges that will allow them, and in extension anyone who figures out their password, to do great damage to the site. Since it is unreasonable to ask for a password change on gaining privileges (or on the web site gaining popularity), the initial password should be secure enough that the risk is sufficiently low. That doesn’t mean enforcing ultra-secure passwords or arbitrary restrictions (which are counter productive anyway), but I’d say any password that can be cracked in five seconds on a Raspberry Pi should definitely be rejected. This obviously includes Password123.
7 Likes
I could not agree more. Today, most sites have ridiculous password restrictions, sometimes making it impossible to select a secure password.
I personally have about half a dozen very secure passwords that change regularly and those password restrictions often times prevent me from using them, in that case I have to fall back to some stupid “passWord129991” because that bypasses the password restrictions.
It’s not possible to force someone to choose a secure password. What I consider reasonable is to forbid empty passwords, because this is often a mistake where the password field was overlooked. All other restrictions should be optional (but with a descriptive warning).
That’s true, but there is no way around it. People just take their insecure password and if it’s rejected they simply permute it until it’s accepted, e.g. “Password123XY” instead of “password123”.
2 Likes
Current good-practice security advice is to have a length restriction of minimum 8 characters for a site like this: no maximum, no character restrictions, no strength restrictions (though an advisory strength meter as others have suggested is advisable).
5 Likes
… length restriction of minimum 8 characters
Can we make the minimum at least 10 or preferably 12? This should allay any ‘too weak’ concerns when no ‘special characters’ are included. Agree with everything else, but the inner pedant asks:
no character restrictions
I assume, not including and unprintable characters which are illegal?
I disagree, that this will not make the passwords any more secure, it just adds to the hassle. There is actually a question about this on Software Engineering Stack Exchange, the answers mostly agree that having too many restrictions is counter productive.
1 Like
Unprintable characters would be inadvisable for the same sort of reasons that using emoji in passwords is inadvisable: support is patchy and you can’t guarantee it’ll work the same across every end device: but that’s on the user’s side, not the software side. We shouldn’t restrict what can be used without very good technical reason to, and since any input will just be converted to bytes and sent through cryptographic functions to produce printable output, accepting unprintable characters is not technically any different from printables.
4 Likes
As a practical matter, this mostly allows users of password managers to have still yet even stronger passwords than they already would, but anything that can help spread the use of password managers is a good thing for security in itself.
1 Like