I didn’t know this when I made my account and fired up keepass per usual to create a massive random password. It takes me nearly 5 minutes of carefully pressing buttons on the screen and trying to keep my location in the password (you can’t see what you entered) just to get in.
One of my pals around that time turned on accessibility features like onscreen keyboards and diligently never typed a password. In a shell, a site, whatever.
It's unfortunate that these sites (Treasury and UK mortgage) were built around this time, but also shows that with all the progress with tech, security is still glacial in places. And like all tech, we get stuck with trends for a while (like skeumorphism in ux design).
Say what you want about skeumorphism, but it at least gave people a fighting chance to figure out what in the world the target actually does.
A lot of GOOD malware don't "sniff keys" because that gives them random stream of garbage that has little value. No human is going to sit there and hand-decipher that garbage. Instead, they either inject browser extensions, intercept at the Win32 layer, or intercept the HTTP traffic upstream of the browser giving them the raw form-fields with URL which can be packaged and sold.
So all TreasuryDirect was doing, when they were doing this, was inconveniencing real people while the malware didn't even notice. Utterly insane. Glad someone had them quit it.
Also a nice example of when security through obscurity is harmful. "If we show a picture of a keyboard instead of taking text input, that'll stop the hackers!"
Basically, 8 characters or more, but prevent the user from picking a password that appears on any of the leaked password lists. Store in pbkdf2 or better; use argon2id per https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
That's it. Simple. No mandatory symbols. No mandatory changes after a period of time. A password strength estimation meter is optional.
If it needs to be more secure, I might require more minimum characters, but no other restrictions.
Also, the ‘no previously leaked passwords’ are gonna piss off a lot of customers.
It dynamically analyzes a password's cracking time, score, and gives feedback based on the password. imo it's a pretty good ux if used right
First, it's not either-or. You can match against zxcvbn strength and some passwordlist.
Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.)
Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.)
Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!
Zxcvbn is imperfect by design. It's a tradeoff it makes for being fast and small.
[0]: https://dropbox.tech/security/zxcvbn-realistic-password-stre...
That XKCD comic came out August 2011, and this article was released April 2012, eight months later. At the time, it made sense to use that as an example of a "highly entropic password" in a blogpost targeting a general technical audience.
It has now been 156.5 months since that comic was released, and 164.5 since zxcvbn was originally trained on its 2011 dataset. "Correct-horse-battery-staple" and its variations are widely used strings and is no longer an example of a strong password.
It's worth being careful about our definition of entropy. The same highly-entropic source generates "hunter2" just as often as it generates "aaaaaaa" just as often as it generates "jpnj6i3".
A "good password" is one that is unlikely to be guessed by an offline cracker. But there are countless strategies an attacker might choose, most of which involve taking a list of passwords and applying rules to them. This is why a highly-entropic source is important (e.g. of all the 32-character passwords, 'weak' ones like "aaaaa..." make a negligible percentage of them) as well as uniqueness ("mP7t6e8TAH..." is a weak password the moment it's leaked in a breach.)
You can't know what strategy the attacker will pick beforehand-- the idea is that it's negligibly likely that an attacker chooses a strategy that cracks your password in a few guesses.
Zxcvbn intentionally takes compromises to be a performant best-effort estimation of how many guesses an attacker would take for your password. (It would improve its estimation of guesses by actually trying to guess your password with `hashcat` and the antipublic combolist, or whatever people are using nowadays, but then it would take eons to provide an estimation rather than milliseconds.)
I suppose an alternative approach would be to open a websocket in the post login page, and if you open the link in your email the server sends your browser a cookie or something, and then you're in. But I've never seen that approach.
12 years old post talking about polish banks and the reasoning :)
I think this is a “the password game” requirement.
It could well be that they're doing the encrypt/decrypt thing, but you can also get the same affect by pre-calculating the slices of password and hashing those slices.
For example, when you create the new user entry, you could take the password, pick three random characters from it, and store the indexes and the hash together in a table row (in your case, something like ("31,98,102","salt$hashfgtd")).
You do that two or three times, and then, every time you ask the user to log in, you randomly choose one of these entries, ask the user to enter the character positions, and check the hash of the result against the hash in the row.
The Student Finance England website used to have a similar setup about asking for letters X, Y, and Z, but it rotated between only a handful of combinations, so I think it probably used something like this.
That said, a few years ago gov.uk took over the SFE login form and modernised it, including replacing the XYZ system with a version where you just enter the whole string, so presumably either they also had hashed the whole string, or they were storing it in a format that was retrievable. Or I guess they still only store the XYZ tuples but do the indexing and comparison logic internally.
Ok, so in the context of your mortgage website, they may be doing the same thing. The motivation may be to stop keyloggers or anyone who is "inside" HTTPS getting the password. The implementation may be a hardware security module which is write-only for the password and which gives a yes/no answer when asked to check a character.
Website: "Please choose a complex password of at least 8 characters including special characters and numbers"
Me: Fires up the password manager, generates a 128 character random password, feels smug.
Website on next visit: "Please enter the characters in the 31, 98, 102 position from your password"
Me: WTAF
Context: Mortgage website in the UK
Edit: It's now dawned on me that they're storing this plain text so that they can do this... or at least encrypting rather than hashing, meaning that they can always decrypt the password.