1) No words! 2) Can't reuse last 24 passwords 3) Excludes some special characters 4) 5 Security questions 5-10) Several other password requirements
Are the security questions case sensitive? Who knows.
^ "I understand that I’ll be required to certify that the information I provide to create an account is true and correct and that I’m the individual I claim to be. If I’m not the person I claim to be, I understand that I’m not authorized to proceed and that I should exit this form now. If I provide false or misleading information, I understand that I might be subject to a fine, prison time, or both."
Enter your password wrong and you're off to jail?
---
Your password must be 8 to 30 characters in length and must contain at least one uppercase letter, one lowercase letter, and one number.
Your password is case-sensitive.
You can’t use personal identifiers such as your first or last name, date of birth, or Social Security number in your password.
---
Here are some error codes the API returns:
["NULL_USERNAME", "NULL_EMAIL", "PWD_ILLEGAL_CHARACTERS", "PWD_CONTAINS_SPACE", "NULL_CHALLENGE_QAS"]
When she tried a variation of "Taylor Swift" it worked fine.
If the company still pushes forward with bad choices its on them, but they should be clearly informed how and why those choices are bad.
Some caveats: 1. Nobody will be convinced to change the position on the first attempt, but seeds of knowledge can be planted in other peoples heads and some of those seeds will bear fruit later. 2. Being not nice, shuts down the passageway of ideas.
Well, the good news is that everything you listed is known as a bad idea to both end users and people who understand security (which is, sadly, not most people who implement security policies).
Using 4 or more dictionary words provides excellent password security and you can do the same for all of your security answers too. There's a variety of free and paid for password managers that solve the issue of trying to remember all your secrets (great for backing up 2FA secrets too).
I'm not sure what you mean by "complicated error messages" but I assume it's errors that they expect the user to fix themselves, otherwise they could return a generic nonspecific error and a unique ID for you to provide when you contact support to get help. While it sucks to get jargon spammed, I feel like pretty standard human ineptitude at explaining an error rather than anything specific to security. I also think it's how many people feel about any error message that contains computer jargon (PC LOAD LETTER!?!?).
> I often wonder how they get away with it all.
My thinking (and experience...) is that most organizations are failing at a lot of things at any given time, even if the business overall is successful. Security is just one of those things. I wouldn't be surprised at a small elite organization not following that trend, but any sufficiently large organization is going to have incompetent people doing incompetent things.
I would not call 44-48 bits "excellent". It works if there's a good password hash being used, but if someone left PBKDF on basic settings then a GPU might be able to do 50 million guesses per second, or for a plain old salted hash 50 billion guesses per second.
The guesses per second, I looked up some hashcat benchmarks to get a rough range.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
It has much to say on all kinds of other password nonsense:
> Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.
> Truncation of the secret SHALL NOT be performed.
> Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.
> In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered.
Complex passwords also should not be required
NIST Special Publication 800-63B – Digital Identity Guidelines.
https://www.netsec.news/summary-of-the-nist-password-recomme...
My favorite is:
1. I go to a website I haven’t used in a while but know I have an account on
2. I sign in with my email and what I’m sure is the right password for that site (algorithmically generated from site URL)
3. Password not valid
4. Ok, maybe this was an older version my my algorithm from way back
5. Password not valid
6. Fine, hit password reset
7. Get reset email and click it
8. Enter algorithmically generated password as new password
9. Error, can’t have that special character
10. Fine, per my rules, replace that special character with next one
11. Sorry, can’t reset password to your current password
12. Aaaaaargh.
(Not saying that simplifying several errors into one message is always bad. I think it's reasonable to just return a 500 without any info for everything that's caused by an unexpected exception on the backend.)
Most recent was setting a password for Rakuten Bank, saving it to my browser password manager, saving it to an offline password manager, and then two days later attempting to login and being told my password has too many characters. What.
It annoyed the hell out of me though when I was trying to put the required special character on the end of my too-long password after a required password change, and the only error message I got was that the special character was missing.
I worked for the online investment banking arm of one of the big Canadian banks a few years ago. Their passwords could only be eight characters long. At one point, I was tasked to do some work on their IVR system and discovered that your phone password was entered by pressing the corresponding letter key on your phone keypad. But they didn't say "2 for A, 22 for B, etc." which really confused me. How did it know the passwords were correct?
And that's when I had a terrifying realization and tested it out on the website - they weren't magically converting your phone presses into ascii characters. No, they were converting your password into the corresponding numerics and saving that. Every single user password was a 6-8-digit number.
They upgraded their whole login system around the time I left that company, including implementing 2FA. Though their 2FA was SMS-based rather than using an known authenticator app system, so it still wasn't perfect.
This sounds like an erronious error, ie the error message displayed is not the correct error message. There was definitely an error but the error was not that you tried the same password as your current.
I hate erronious errors with a vengance, because they not only break user workflow but they break helpdesk work flow as well then it gets escellated to an engineer who quite often cant fix the actual erronious error but knows what the actual issue is and fixes that anyway.. meaning the erronious error never gets fixed and will mow hang around to chew up everyones time all over again.
such a silly way to waste so much time, over and over.
What exactly is this based on?
I know I've seen that listed as a requirement (well, actually can't be one of the last 3) on some systems that have annoying password requirements.
You want some indication that any leak of your current password actually hasn't been mitigated. A failure message that your password hasn't actually changed (due to being identical) is functionally the same as allowing the password change and giving a warning that the passwords were identical (modulo some back-end details like if the password salt has changed and if the password change date has been updated).
For umlauts, restricting the amount of support calls from people abroad where the keyboard doesn't have them.
For others, particularly when mainframes or other truly old legacy systems are involved, encoding issues somewhere along the transport chain.
It is really hard to listen to any security recommendation from anyone in the industry when there are SO MANY bad password rules that restrict what actual good long passwords are. Length restrictions, restrictions on special characters or UTF-8, password rotation rules. These examples of bank logins at major banks absolutely blow my mind.
and is site-specific with some leetcode subs or a magic number suffix is about the strongest password for login and for long-term user security and usability.
Maybe in another 15 years the security people at corporations will get their act together?
Maybe sometime we'll get legislation with some actual teeth on login security?
Password managers usually are either password-protected themselves or have biometrics, which suffice to deter random thieves. In fact, password managers are not going to show your password in the first place, they are going to silently fill in password prompts. The password cannot be clipboard-stolen, screen captured, or key logged. It is even more difficult to fish you (if the password manager doesn't detect the right program id/URL, it won't fill your password in -- unlike you).
If someone is looking over your shoulder with a supercamera he can get one password. If you are using a password manager, that's it. If you were using "an algorithm" to derive your passwords it is now possible he can now easily guess ALL your passwords. Most people aren't that good remembering good "algorithms" anyway. Maybe he needs to capture two passwords to do so?
Unless your algorithm is truly good, in which case you likely have to store it somewhere and that becomes your "password manager", which shares the same cons as a password manager itself. You are even at risk of your "algorithm" being guessed through a couple big password DB leaks, which are sadly ridiculous common, and this by itself puts you more at risk than worrying about supercameras.
I however don't have anything good to say re password managers that sync passwords over a centralized service, or worse, do so without proven E2EE.
I'd replace "engineers" with "product owners". I'm sure the engineers at Microsoft know some of the stuff they're doing is braindead and are unable to do anything about it.
This is Capital One by the way. My account was originally ING Direct, then Capital One 360, before being fully incorporated into the rest of their nonsense, and I assume that's related to the username situation.
Edit: The issue was with the password field, not the username.
How are blind people supposed to use this UI?
Obviously, if the computer reads aloud the password as you type it, it's an absolute win for security, and I'm sure some PMs somewhere are quite content with a job well done.
For the curious, here's the login page: https://mabanque.bnpparibas/fr/connexion
It's no big deal... you'd need to be blind to miss someone nearby listening in!
I've had business and personal accounts with SG, La Banque Postale, BoursoBank and CIC and they all worked with those 6-character "visual number pad" logins.
I think the others are just copycats. Someone must have come up with this first, and the others figured "yeah, that looks so secure, let's do that, too". If I had a penny for every CSO who justified some stupid "security" idea with "everybody does it, why shouldn't we?" I'd be so rich I wouldn't care about this crap anymore.
It's a bit of a 'Foreigner in China' stereotype to whine about how absurdly difficult it is to go to e.g. the bank or a hospital as a non-native because it happens so often.
Ex, i created the account with "mySuperAwesomeHunter2Password".
But the limit was somewhere in the middle so I had to enter "MySuperAweso" to log in.
They fixed it since then but I stopped using it except as a payment proxy. No money will ever be stored on paypal after that nonsense.
My bank account (HDFC india) starts with 00. Dare send it to any accounting person who will copy paste it into an excel sheet and bang.. the prefix 00 is gone. Now they will complain that your account details are wrong. Took me a few months to figure out what was really going on.
Here in USA, Citizen's bank, iirc a subsidiary of Royal Bank Of Scotland, has had a bug for years that prevents me from changing my password. The only way to do it is via a series of tech support calls, despite the fact that they've had an open ticket for years. The source of the problem? Can't do it on an account where the email address (not the username) has a less-than-3-character-long name, as in "[email protected]". I own a small company and setup initials for easy-to-use email addresses, and found zero problems anywhere else in the world. But these clowns seem to need "abc@..." to function correctly.
I've found bankers tend to not be the brightest bulbs in the box, and this is but one example.
Then they got bought by another bank ... and now, they require *6-digit* PINs/passwords + no certificates. Yes, there's 2FA involved now, but seriously, 6 digits?
Hasn't been best practice for a decade.
> Insane rules for constructing passwords.
There needs to be a minimum standard. Generally length is enough, but the special character type stuff is annoying.
> Completely undocumented password requirements that you just have to figure out by trial and error.
I haven't come across this.
> Complicated error messages full of security jargon. "Secret Questions" that you can't remember the answers to.
That's a you problem.
Y'all complain about password breaches but want to use Mypassword69! for everything. Pick a lane.
Don’t defend these idiotic practices.
and then the deeper question is, why do i need to create an account for this?
That... That is literally what these "security practices" force you to use. You literally used an example of the ubiquitous "at least one uppercase letter, one special character, and one digit" requirement
This entire thread is about places that clearly have no clue about best practices.
> I haven't come across this.
You sweet summer child...
- In MS Authenticator, having to click on each subject rather than just showing the code immediately. If Google's Authenticator can show the code, why can't MS's?
- Azure DevOps randomly redirecting to the login form and back while already logged in.
- Azure DevOps randomly opening an authentication popup (presumably some SSO stuff) and closing it again
- Clunky-looking Office365 account management flows
If you have multiple accounts open in the same browser session, regular Azure portal won't remember which one you chose when opening in a new tab. If you got to a new tab by clicking a link, it will send you to select which account you want, then helpfully send you to the portal homepage, forgetting the initial URL.
Well, that was before. Since a few days, they seem to have improved the experience, since they no longer ask which account I want to use, but helpfully pick the first on the list. No, they still don't remember which account was already being used when clicking the link. And no, switching accounts from the top-right icon doesn't keep you on your current page but sends you back to the portal homepage.
Then there are other webapps which seem to implement their own login flow: they figure your session is expired, but don't allow you to switch accounts. The only way to use a different account from this flow is to sign out of the current one, which, of course, signs you out from everywhere. The solution is going to a different site, say myaccount, login with the second one, go back to the first site which now allows you to choose.
Container tabs[1] are great for these. My work browser has a separate container for each of my frequently used Azure logins. When I need to use one of those pesky apps, I just open it in the respective container.
[1] https://addons.mozilla.org/en-US/firefox/addon/multi-account...
The worst one involved hitting cancel 8 times in a certain window, which you let you in. Lol
Years ago, I went through this process with Blizzard:
1. Blizzard started deactivating my World of Warcraft account on the grounds that I hadn't paid my subscription.
2. I would log in and pay for a subscription, reenabling the account.
3. (Steps 1-2 repeated several times. Blizzard never provided any explanation beyond the fact that, in their opinion, my payment was invalid, which it wasn't.)
4. After several rounds, Blizzard disabled the account completely, requiring me to contact customer support.
5. Customer support, for the first time, informed me that the reason my payment was viewed as invalid was that the preferred payment card on my account was set to a different card. The card I was actually using was also listed on my account, but it wasn't the preferred card, which made it invalid.
6. Since my account was disabled, I didn't have the option of paying with my preferred card. I had to answer my secret question.
7. Since I am not stupid, my secret question didn't have an answer. It was a long string of random characters which I didn't know. But customer service happily accepted my oral answer of "it's gibberish", defeating the purpose of the secret question.
So I guess the lesson here is that the correct way to answer a secret question is that you need to provide an answer which...
(1) Looks like a real answer when customer service looks at it, so that they have a better chance of rejecting someone who doesn't know the answer; but also
(2) Doesn't belong to the class of answers that would be easy for someone to guess, such as a car model when they ask you for the model of your first car.
These requirements are incompatible with each other. I don't know what secret questions are supposed to be doing. And I have to note that my assumption that there was no reason for anyone, including myself, to know the answer to my secret question would have been completely correct if Blizzard hadn't made the decision that using a payment card that was already registered to my Blizzard account was a sign of fraud.
I thought up this schema after the last and only time I needed to use a secret question over the phone, when I read 32 ASCII characters to an Apple employee (which didn't work, but then they enabled a skip button for me to use).
So I guess in the end their recovery process was susceptible to some good old-fashioned social engineering.
This is against all current commonly applied security recommendations (NIST, OWASP).
All because some 15 year old security document said that's what all their products adhere to.
#YesterdayILearned the highly-appropriate phrase "breach fatigue."
The only password rule that needs to exist is "use something you've never used before". That really does make it difficult for most users though.
You COULD have a longer password, but the extra entropy is probably excessive. It probably increases the chance of password reuse problems, so pragmatically it may be worse.
I wouldn't recommend this approach in general, however.
If not, do they also do the weird Symantic codes that're literally vanilla TOTP under the hood[0] but wants you to be locked in to a proprietary app instead?
[0] https://locima.com/2019/06/01/replacing-symantec-vip-with-a-...
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.
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.
companies hire data science to ascertain human behavior, but this is not understanding the customer. if you want to improve your products and actually understand the customer then start giving your customer service or customer experience departments a financial boost instead of treating them like the bottom feeders of the entire company.
> I often wonder how they get away with it all.
unregulated industry + no union. tech workers practically beg to be exploited.
Even my simple requests like not auto flagging emails from confirmed and fully validated Microsoft services gets denied because it’s “too hard” so everything except internal users and random whitelisted services like github and azure AWS is instead flagged as suspicious, causing alertness fatigue.
I’ve reported major logic problems to many major companies and usually the only response I get is an indirect followup email through HR or some other non technical people sent to the entire distribution list as a followup saying how it’s technically better than what was there before (it’s scientifically and mathematically not) and that we just need to do it.
I never get recognized or win bug bounties because there’s always some loophole where I didn’t actually help them and they just magically fixed the long standing issue by coincidence after I reported it.
Most recently, I discovered a “feature” with Microsoft OAuth that has a severe flaw and could essentially shut down all MS OAuth functionality, and all consequences branching from that. Still no response.
I’m not even trying to find these. They just keep getting in my way of trying to do work.
For example, I have to authenticate up to FIVE times per authentication, per authentication —- Auth syncing can be slow leading to multiple auth requests that would otherwise only need a single one to propegate.
5 authentications * 5 programs needing individual (slow-sync) auth = 25 authentications I have to already pass to be able to start standup or pass in order to un-hard-freeze my live demo to potentially hundreds of engineers.
Imagine driving your car, and the steering wheel locks when it loses internet connection (like in a tunnel or just randomly) or because the re-auth period has passed. Security devs don’t want to full stop the car because they’ll get yelled at, so just lock steering so they can’t steer home.
Well now if you’re on a highway, that’s pretty stressful and dangerous. But it’s like they are just salting the wound by adding a series of glitchy minigames where you have to first read all the spammy popup dialogs, and then solve a Baldi’s Basics math puzzle, and then rotate a ball to not be upside down (?) and then manually match a missile launch code.
In the case of password construction and complexity, we’ve learned that rotation and complexity leads to worse password practices.
https://pages.nist.gov/800-63-3/sp800-63b.html
However many large companies do not adhere to the latest NIST guidance (which is many years old by now).
This is why password complexity and rotation is still so nuts.
This really rings true. Just think of all the nonsense you have to deal with in the name of "security." Mandatory password change intervals. Insane rules for constructing passwords. Completely undocumented password requirements that you just have to figure out by trial and error. Complicated error messages full of security jargon. "Secret Questions" that you can't remember the answers to. And on the other side of the coin, the security of these systems themselves is like a sieve. So many data breaches, information disclosures, they are in the news almost daily. I often wonder how they get away with it all.