Hacker News Reader

Comment by SoftTalker | Hacker News Reader

"This is a small example of a big problem with usability and cybersecurity. This is what happens when apps are developed by engineers who don’t have a strong knowledge of customers"

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.

View on HN

My bank introduced "usernames" at some point, breaking login with email addresses, but didn't document this fact, or enforce that usernames not be set to email addresses. For a few months, every time I went to login, I had to use the "find my account" function, and each time I would again set my username to my email address (and why wouldn't I, it had been my login credential for nearly a decade by that point). At no point did it ever enforce a restriction on the @ or . in the username, until I went to login. It took me literal months to figure out and set it to something else.

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.

At a Mexican bank, Banregio, there was a character limit to the username on mobile but not on web. So I originally had a username that was accepted at registration but not when I tried to log in on my phone and it wouldn’t allow me to input my entire username.

Edit: The issue was with the password field, not the username.

USAA had a similar issue for some time, but with the password field. One interface (web or mobile, I don’t remember) would silently truncate the password. You couldn’t even tell it was being truncated because it was all **!

Actually, looking at the credentials in 1Password for this bank, my issue was with the password field, so similar to USAA. Mobile had a 15 character limit.

Speaking of character limits, my bank, Swedbank Latvia, used to have a 16-character limit on passwords. After lots and lots and lots of pestering over various channels, they finally fixed it. But the "fix" was to add a maxlength attribute on an input field. So the field will accept the 16 first characters and ignore the rest (password fields are masked so the user cannot see the field is not accepting their input). So yes, I could now set my password to "SwedbankSecurityExperts", yay. But I could later log in with "SwedbankSecurityIncompetence" as well...

Well, 16 isn't so bad. Here, in France, BNP accounts must have exactly six digit passwords. They're also incompatible with password managers: you have to click the number on a visual number pad.

Surely that must afoul of some sort of French laws regarding accessibility?

How are blind people supposed to use this UI?

To be honest, I'm neither a web dev/designer nor do I have bad sight, so I admit I don't really know how accessibility works. I expect this to be compatible with screen readers somehow, they even say they take this seriously. But from a quick glance at the Accessibility tab in Firefox, I see many complaints about "interactive elements must be labeled".

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

La Banque Postale actually has a toggle button to make the computer read the code out loud as you type it.

It's no big deal... you'd need to be blind to miss someone nearby listening in!

Maybe it's a French law or something.

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 doubt it. N26, which is granted a "new bank", doesn't have that, even though it now has an actual French subsidiary, complete with French account numbers. My password with them is way above 6 characters, and contains numbers, letters and symbols. The login page has a regular password field.

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.

At least you can login. Alipay in China has (or had, it's been a while) a max length of about 16 characters for your full name, but when linking to your bank account it compares with the whole string, so any name longer than 16 characters will always return false.

I've spent a lot of time in China over the years and most of their tech systems are built on the assumption that only Chinese folk will ever use it. In this case, the vast majority of Chinese people have a 2, 3 or 4 character name ('why would you EVER need 16, silly 老外?')

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.

The character limitation is also a problem in Korea. The thing that makes it worse is that your name on your alien registration card (think Green Card) is used to open your bank accounts. If they don't match you'll have a hell of a time doing any sort of online or mobile transaction since the systems are tied together. Only recently some banks have recognized this as a problem and extended the number of characters allowed.

Japan also has this issue.

I had that problem with a major US bank. Copy and pasting or retyping the password worked, because doing so hit the client side JavaScript that truncated the password. If the password manager filled it out, it wouldn't work because it bypassed that JavaScript.

At some point paypal had a character limit on the password, but wouldn't warn you when you set the password. So I set a long password, and was denied entry when using it, until i figured out the limit.

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.

This is nothing.

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.

Not to mention the disabled copy pasting.

Had a similar thing happen when my small regional bank was rolled up through a couple M&A's and I have 00s and my regional account number remained. If I ever have to call them I have to explain the situation because when I start with 0s they don't believe me.

Yup.

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 "ab@mycomain.com". 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.

Up until a few years ago WF didn't process case in passwords. you could set your password to Hello and log in with hello

I think Bank of America doesn't allow exclamation mark in password. It is strange. One of the largest banks on earth.

My own bank used to have [A-Za-z0-9] passwords with a character limit + browser certificates. I thought the former was pretty bad (and it's always alarming, as it tends to imply they're storing it in plaintext if they even care what the characters are ...).

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?

Yesterday I had a good example of this.

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.

Maybe we need a corollary to "don't roll your own crypto": "don't roll your own password scheme".

So what is the ‘standard’ then that doesn’t suck?

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

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.

Ah, yet another standard. How many years do you think before it’s obsolete?

Also, the ‘no previously leaked passwords’ are gonna piss off a lot of customers.

I think you just picked up the goalposts and brought them home with you. Why ask for a standard in the first place?

Because this is what, the third NIST standard on it?

Things can change? The newer standards improve upon the errors of the old ones and presumably make the old ones deprecated

8 chars is not sufficient. The Hive strength estimates switched to Bcrypt this year but there are still weak systems out there and you should set passwords assuming MD5 which currently demands at least 12 chars for typical users.

What's your opinion on zxcvbn[0]?

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

[0]: https://github.com/dropbox/zxcvbn

Misused, zxcvbn offers its own security issues.

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!

It indeed is. The bad password you're thinking of is "correct-horse-battery-staple".

Both are bad passwords, and zxcvbn states both are good. Try it here: https://lowe.github.io/tryzxcvbn/

Zxcvbn is imperfect by design. It's a tradeoff it makes for being fast and small.

You might want to re-read the introductory article [0] where the authors themselves look at that specific password.

[0]: https://dropbox.tech/security/zxcvbn-realistic-password-stre...

Yes, I'm very very familiar with this :) I stand by my assertion, "correct-horse-battery-staple" is a weak password to use today. Zxcvbn reporting it as secure is an example of where it's weak.

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.)

Better yet, don’t use passwords at all. I’m personally fond of the magic link sent to email method of authN

I'm the opposite. I deliberately avoid checking my email outside of predefined times, and hate it when a website assumes that everyone is happily living in their inbox.

This doesn't work well if you aren't working in your default browser and if the link expires after a single use. For instance, if you're trying to log into an app (not a website) and the redirect to the app doesn't work when you tap the link in your email.

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.

Ran into the same thing with Santander Bank in Poland. I have been online since the 90s never seen that password scheme ever anyplace else. It´s like who comes up with this insane shit.

https://security.stackexchange.com/questions/7467/how-secure...

12 years old post talking about polish banks and the reasoning :)

Until recently, treasurydirect made you login using your mouse by pressing a keyboard laid out on a screen. This is a government website in the US for buying treasury bonds.

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.

I got around this by just editing the HTML. Worked like a charm

Yeah, you could just delete "readonly" from the input, then try the password manager autofill again. Thankfully no longer necessary.

Also demonstrates how pointless that theater was.

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.

a lot of efforts to prevent malpractice are like this. Anti-piracy software only really hurts paying customers for example.

These days I'd be scared that fails some biometric spyware and gets your entire account instantly banned+deleted with no recourse.

I found some sites recently that have big ASCII banners in the console log when you open devtools telling you to stop being naughty.

Both of these reflect a security approach from early 2010s when keyboard sniffing was the worry-of-the-week. The idea was that even with all keystrokes intercepted, the full pw was never sent via keypresses.

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).

> (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.

You could open dev tools and modify the input then pasting worked.

Incidentally, you could find the hidden input in developer tools, and just type your password there like a normal person. But yeah. That site is so bad that I never bought more ibonds even though they were a great deal.

That's kinda hilarious though.

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!"

That's a good one. One of my personal favorites was a device that truncated long passwords in the set password function. Didn't take too long to figure out what happened but I was worried for a moment I wouldn't be able to unbrick that device.

> “Please enter the characters in the 31, 98, 102 position…”

I think this is a “the password game” requirement.

> 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.

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.

>It's now dawned on me that they're storing this plain text so that they can do this...

https://en.m.wikipedia.org/wiki/Shamir%27s_secret_sharing

How would you securely implement this scheme with SSS?

Sometimes passwords are stored in plain text to improve security. An example is K in mobile telephony, a number shared between the home network and the USIM. This is used for mutual authentication and establishing a cryptographic session key. There is no concept of a certification authority (which can be subverted) or a signature - there is just a shared secret, stored in plain text, so there are minimal trust requirements. But stored in a secure piece of hardware with write-only access for K. You pass a challenge in, and get back a number which can be used to prove identity, and a number which can be used to establish a crypto context (here I am simplifying by not describing the mutual authentication).

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.

> Completely undocumented password requirements that you just have to figure out by trial and error.

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.

This has bugged me a lot. Have I been gaslighted? Like, do sites lose my password? I can swear there have been like 10 occasions in the last 20 years where I had to reset my password where I am pretty sure I knew it.

That’s how I lost my Hotmail account.

They emailed you the password reset link?

well I am definitely to blame though it still makes me sour. When I created the account it was a time when the issue of corporations abusing your information was a hot topic. So when I created the account I was in the mindset that I should not give all my information to any company so I made up my details. So I did not have a real name it was obviously fake and I used a fake birthday. I had all this information but I strongly believe they realized my name was a fake and cut me off. I tried to do the reset link but it never worked. Still to this day I get the occasion email from that account as I did set it up to forward to my gmail. Just yesterday I got an email about verifying my insticart account and it was not me. I am still bothered years later that I was logged out and my password that I am sure i knew did not work. I feel like they forced me to try a reset and when I did it failed. That was my first email. I wish I could get back in. I screwed up with the fake info. I was young. I have given up and don't think there is a fix at this time, it has been years. I have grieved and moved on.

I'd bet that some sites had their DB leaked/hacked, and just marked all the current passwords invalid to force a reset. Hopefully, it wast just the hashes that were leaked...

Oh ye that is a good theory.

Just a few hours ago a pretty well-known site was telling me my password was wrong. The same one I'd copy pasted and logged in with for years from my password manager, including as recently as within the past 24h. I tried their app and it logged me in just fine. This wasn't the first time I'd had such issues with the site. Why do these happen? No idea, they must just hate me.

I had this with Duolingo. Their login fails if the browser can’t connect to recaptcha.net. But it just shows a generic “incorrect username/password” message.

In my case I'm pretty darn sure it's something on their backend. Some race condition or lock or something that prevents login while stuff is being updated. The most frustrating part is the gaslighting, not the failure.

Or it could be bad UX, displaying the same error message for two different errors.

(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.)

Or a backend cache miss

Ah, this is a good debug. I wonder how many times this is silently happening on other sites?

Very common, the first thing I check when this kind of error pops up.

Well I am glad I am not alone. It is a strange feeling to know you are right and the computer saying no making you doubt yourself. Like, my first reaction is usually to write the password in clear text and copy pasting it to rule out keyboard issues ...

I swear to god I regularly have to change passwords I just set a few days ago, and/or saved to an external password manager. Yes, some incidents are probably me messing up somehow, but it seems to happen way too frequently even assuming I'm an idiot.

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.

I experienced this with Spotify multiple times.

You want a good one? Silent password truncation on account creation without a required relogin so on return my saved password doesn’t work and I need to reset it.

This has nothing to do with knowledge of customers but really just a lack of caring.

ugh this one is by the worst and the only way to discover is knowing your password is 100% correct. I usually will drop the password length from 24 -> 12 to sort it out.

I had something similar happen with an HP Ethernet switch years ago. I was looking at a factory reset (and had no backup of the config... ugh...). I started re-entering the password with 1 fewer character on each attempt and finally got in. Maddening.

My bank used to do this too, but they were nice enough to silently truncate the password input on the login form as well, so you wouldn’t ever notice unless you accidentally did something to reveal the truncation.

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 had a bank that did this and it took me months to figure out WTH every time I tried to logon it failed, but when you reset the password it accepted longer length passwords while silently truncating them and getting you back into the account. I finally figured out their max password length was 8 characters anything longer would result in failures past the initial logon after a reset.

Making a throwaway for this since my main is linked to my real identity.

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.

I've absolutely had this happen with some US bank in the last 4 years. I can't remember which one, but they had me essentially type in my password over the phone in the same way, with * being the button for any non alphanumeric character.

My password is "***********"

Yep I ran into this with an Oracle OpenAir. Needed to reset my password so I fire up 1Password, generate a 50 char PW and set that. It works for the first login but when I logout and log back in it tells me I have an incorrect password. Go through a password reset a few more times before I finally realize that they are just taking the first 12 characters of my PW and using that, and not telling me that they are doing that.

>11. Sorry, can’t reset password to your current password

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.

> 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.

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.

I disagree. It’s pretty normal to invalidate the current password on password reset, and to also not allow the same password to be reused.

I agree with you, but would phrase it differently.

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).

Oh yes, you're not alone! That secret battle between "must have" character classes and "can't have" character classes is the bane of all mental password algorithms. Where do the "can't have" rules come from, anyways? Smells like not using hashing (and even then, those rules would still be weird). But it can get even better, when the site refuses to accept third level domain email addresses. Bonus points when it did, but at some point stopped.

> Where do the "can't have" rules come from, anyways?

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.

This is (part of) why we recommend password managers to people, not deterministic generation algorithms that still require keeping a list of logins with exceptions.

Except the password manager becomes a central point of failure. If someone gets your phone, opens your password manager, boom they have keys to the castle. Because let's be honest, the password manager is on the phone, and there's no way keyloggers or screenshot backdoors get on there, and there's no way someone isn't looking over your shoulder with the latest iPhone Pixel Galaxy supercamera across the room.

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.

https://xkcd.com/936/

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?

> Except the password manager becomes a central point of failure. If someone gets your phone, opens your password manager, boom they have keys to the castle. Because let's be honest, the password manager is on the phone, and there's no way keyloggers or screenshot backdoors get on there, and there's no way someone isn't looking over your shoulder with the latest iPhone Pixel Galaxy supercamera across the room.

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.

Deterministic generation algorithms are also a central point of failure - if your key gets leaked, you're cooked.

I’m on my sixth bank password at east because almost every time I go to reset it, I get the “can’t use current password” error despite trying all of my algorithmic passwords

So far https://studentaid.gov/ is the worst I've come across (I don't want to enter fake info^ and I can't duplicate my account to double check the requirements). From memory it was something like:

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."

> 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?

Might, not will.

Hopefully "Fakename Q Notarealperson" won't get me arrested… Here's the password help message:

---

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"]

The UI doesn't expose the password error codes. It just says “You entered an invalid response. For more info, select the help (?) icon.” (The NULL_USERNAME and NULL_EMAIL errors seem to be spurious in this context.)

Hmm I just made an account two days ago and it told me no words allowed in the own. The email link they sent me to sign up no longer works, so maybe they changed something?

So I had to guess that spaces weren't allowed?

thank god it returns error codes.

i hate apis that only return strings meant for UI display only.

If only the UI did display anything useful here too!

Reminds me when my daughter made her Roblox account. They had some rule "don't use your real name" but they never asked her for her real name, so couldn't validate. They would arbitrarily fail a lot of chosen usernames that were made up fake names.

When she tried a variation of "Taylor Swift" it worked fine.

Stud3ntA1d24 here we come!

> Just think of all the nonsense you have to deal with in the name of "security."

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.

> Using 4 or more dictionary words provides excellent password security

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.

How does that math work?

The bits, I'm assuming a list of about 2k-4k words. The XKCD example is 2k, so 11 bits per word.

The guesses per second, I looked up some hashcat benchmarks to get a rough range.

Is there actually some "professional consensus" on password reset policies (in form of report or journal article or something similar)? If someone could share, I'd love to refer to it in my org to stop resetting passwords every n months.

There are the NIST guidelines on "memorized secrets" (passwords): https://pages.nist.gov/800-63-3/sp800-63b.html#5-authenticat...

> 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.

Thanks!

Password resets should only be performed if it is suspected a password has been compromised.

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...

Thanks!

“Mandatory password change intervals”

This is against all current commonly applied security recommendations (NIST, OWASP).

And the rest of the world hasn’t gotten the memo. Rotating passwords was best practice for so long that every standard required it. Those haven’t been updated. Until it’s considered to be actively harmful and you fail audits for it, it won’t die. :(

I had to push back at my company after getting acquired multiple times that no, I am not implementing your much worse password policies that NIST has argued against for years.

All because some 15 year old security document said that's what all their products adhere to.

Microsoft SSO/auth flows have that feel in general. Really feels like something hacked together. Some examples from the top off my mind:

- 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

MS Authenticator will show the codes for TOTP if you go to the hamburger menu and select "show codes".

Hah, you're right. Thanks!

I only very rarely use Azure DevOps, but that seems tame.

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.

> 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.

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...

I used to use those, too, but I’ve started using a yubikey and azure doesn’t support those on Firefox on Linux. So now I’ve begrudgingly switched to chromium for my azure-related needs, with separate profiles, which is a PITA compared to containers.

Authenticator is buggy. When they made it easy to report vulnerabilities back in 2016-17, a colleague and I were able to pretty trivially compromise the product about 5 times during a PoC - and we weren’t trying to do so!

The worst one involved hitting cancel 8 times in a certain window, which you let you in. Lol

Yeah, DevOps is extremely bad with credential caching and refreshes. Sometimes after you elevate privileges, you'll see the privileged UI options and then they'll disappear on next page load.

Something tells me those kind of mistakes are not done "by engineers" / "by developers" – who rarely have any saying at all and if they do they are ignored more often than not – more likely that's incompetent pseudo-architects and/or product owners/managers.

This isn't engineers doing that. It's CYA IT cyber policies.

Sure, but a lot of engineers aren't completely blameless. They should push back and explain why these are bad choices just like I would expect a building engineer to say to me that cardboard is not the ideal load bearing element for my skyscraper.

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.

Pushing back is a great way to lose your job or get past over for pay raises.

In bad orgs, yes. In good orgs you get appreciated for speaking up and communicating what will be future problems.

Ok and? Some people work in "bad" orgs.

We all can choose to either just follow orders or try to influence the direction.

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.

Usually this nonsense is driven by regulatory inertia out of control of the org.

It's usually driven by industry standards, not government regulations.

Many large orgs, even if individual companies are doing "fine" (not gonna say perfect, but also generally competent) have a parent organization that manages all this audit and policy stuff. In my experience the parent org is nearly impossible to change from the direction of bottom-up. I can get someone to forward an inquiry to them but it takes forever and from their side it's going to look like "hey boss, so, 4 of the 5 subsidiary companies passed the security audit already 2 months ago and the 1 that didn't pass is trying to tell us to modify the policy" to which they'd say "how did nobody else mention this? sounds like they are being difficult. Can we just hurry them along? The audit is already overdue and we need all companies passing for this quarter" and the response you'll get back is essentially "deal with it"

All in the name of audit check boxes.

Those rules sound more like they were developed by admins that don't know proper security and so they add complicated rules to feel like they are improving security.

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.

I actually blame the auditors.

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.

My bank password is 5 digits + MFA. I am FORCED to have it 5 digits. I can’t use any other type of passwords with them.

That has some nice attributes though. Five digits should be quite easy to memorize, avoiding written down passwords. Most phone PINS are four digits, so you avoid phone PIN reuse. Realistically, the second factor is providing the bulk of the security. If that's a typical six digit TOTP, and they validate the PIN and TOTP together then an attacker has a one in one hundred billion chance of guessing correctly (10^5 + 10^6). Add in rate limiting by account and IP address, account locking, and other tools and that's extremely secure.

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.

USAA?

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-...

Complexity is the enemy of both security and usability. I had a day last week where I had to authenticate 28 times to different services due to forced re-auths. No security benefit. None. It cost me 2-3 hours of my life. The IT team needs to realize their security is costing our company 4102avg_hourly_pay*26 for this. That’s a lot of money for zero benefit.

A few years ago Yahoo forced a password reset on old accounts. People had to remember the answer to secret questions from many years back, instead of the password they could enter correctly. And if they couldn’t guess the secret question, they were simply locked out of their email account. Utter insanity, but these types of quirks are everywhere still. Banks have strange password rules very often. And they may support only SMS 2FA. United Airlines still forces users to enter secret questions and answers. Medium has a bizarre “magic link” workflow. Etcetera.

What's especially terrible about this is that secret questions only weaken the security of your account, so someone doing the right thing will have provided a random answer unrelated to their life.

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 generate five random words and store them in the comment field of my password manager. It ensures they are at least pronounceable when asked over the phone.

Have you tried providing five different random words and seeing whether the person on the other end will take them?

The chance to do so hasn't occurred yet. Might be interesting to try, but it doesn't happen often enough and my priorities tend to be different when it does.

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).

You've probably just solved a mystery with my Minecraft account. A good while ago it got "hacked" while having a strong password (random and unique), plus all security answers were filled with gibberish, which I diligently kept backed up somewhere. At that time I also hadn't logged in for over 2 or more years. Eventually I got it back through a proof of purchase process, but I couldn't ever figure out why it was taken over. Since no other account got compromised, I could reasonably assume my computer wasn't either.

So I guess in the end their recovery process was susceptible to some good old-fashioned social engineering.

"This is what happens when apps are developed by engineers who don’t have a strong knowledge of customers"

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.

It's likely that the subject of overwriting accounts has been discussed with business more than once, but the business are so stupid that they do not see it as a problem, or think that if anything goes wrong (as it inevitably will) they will loose their pension. So nothing changes. All software companies have an expiry date and Microsoft is a couple of decades past its own.

engineers typically do not understand people very well as a baseline. i think engineering attracts the type of people who struggle with social behavior. you can't make it work unless you filter those engineers out and companies do not hire engineers to understand the customer anyways.

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.

My favourite recent example was an app that made me create an account, and allowed me to provide a 24 character password, which then sent me a validation email requiring a login on their website, where a 20 character password limit was in force.

Don't forget "business objectives" i.e. making it work, but be incompatible with other authenticators and claim that other authenticators are inferior. Classic Microsoft FUD combined with low quality of product.

> So many data breaches, information disclosures, they are in the news almost daily.

#YesterdayILearned the highly-appropriate phrase "breach fatigue."

I’ve been reporting major problems nonstop for the past like 20 years. It usually takes me less than 5 minutes when I first learn of some new security feature to find a problem with it. Most of that 5 minutes is physically writing my email to security highlighting major oversights. I don’t know how these people get jobs and gatekeep me out of both hiring or my scientifically accurate and backed feedback for not passing the buzzfeed security quizzes for certifications. I’m otherwise a full stack software engineer.

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.

> Mandatory password change intervals.

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.

I encounter some bogus undocumented password constraints probably half the time I create an account. Usually it is a maximal length requirement that is not mentioned in the error message.

Don’t defend these idiotic practices.

I'm not. The only time I've seen a maximum length password was like 10 years ago on Dell's IDRAC I think? I just don't think the complaints being thrown out here are good arguments.

i just had it happen day before yesterday to create an account for a service to do a background check for a new job. it rejected my password without saying why and i could only get past it by shortening it to 15 characters.

and then the deeper question is, why do i need to create an account for this?

Not defending the max length, that's stupid and probably some old AS400 thing that got built into the system, but the account is for auditing obviously.

i don't see what's obvious. what is being audited? why is my email address needed when i'm giving them my id and ssn?

Look at Microsoft's personal accounts (live.com or whatever they are calling it this week) - they still have this limit.

password too long is such a stupid reason to reject a password

> but want to use Mypassword69! for everything

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

And I think that's fine. Unless you're going to ask for 24 character passwords. Pick one.

correcthorsebatterystaple is 25 characters though.

> Hasn't been best practice for a decade.

This entire thread is about places that clearly have no clue about best practices.

> I haven't come across this.

You sweet summer child...

Reply on news.ycombinator.com