Hacker News Reader

I have little faith site developers care about password managers. Many even try to block them from working due to some perceived notion that they are insecure.

I remember using a company-mandated pension website which required a very long password with a comprehensive selection of complexity requirements. To log in, the password had to be entered twice, but they had disabled the ability to use a password manager to populate them (I forget the exact mechanism). To me this is the worst of all worlds. If you put people off using your website, you are less likely to have breaches - security through misery.

I wrote to them pointing out the issue and apparently it was put on their backlog for the following year. I think I received an update about it a couple of years later.

My broker asks for 4-5 random letters of my password each time, making password managers unusable as well. Thinking about it now, how would you encrypt a password using this method? Create hashes of every combination?

You wouldn't encrypt/hash it, since 4-5 letters (say 30 bits) is trivial to brute force anyway. Talking about offline password encryption/hashing is a bit of a red herring anyway, since it distracts from the fact that you're still sending your full password to the server for verification each time, so if the server is compromised for any length of time your password will be as well. Reusing passwords is broken: you really need different passwords for every service, and then it doesn't really matter whether the server stores them in plaintext.

Asking for random letters is a poor man's version of a zero knowledge proof. It's only marginally more secure than asking for the full password (if you want to break into an account you need to observe someone entering the password a few times instead of just once), at the cost of a very crappy user experience.

> you're still sending your full password to the server for verification each time, so if the server is compromised for any length of time your password will be as well.

The key difference between storing plaintext passwords and hashed passwords is that with hashed passwords, you can only compromise users who log in during the interval when the system is compromised, and even then, only for worse compromises (eg if all the attacker gets is arbitrary disk read, compromising hashed passwords would be impossible in most scenarios.)

> users who log in during the interval when the system is compromised

Why only then?

Because the server doesn't store the password, only the "password hash" of the password. So if the server isn't compromised during the login there's no way for the attacker to learn the password itself.

A lot of these sites will even change the letters they ask for every time you reload the page. So the number of observations is probably less than 10. Maybe 1 if you have access to decent chunk of IPs (assuming they will block you if you reload the page too many times).

Can’t the hash be computed through some browser API? The browser can then visually show when plaintext passwords are being sent.

If you're willing to rely on client-side code for authentication, there are better mechanisms, such as https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

There is a standard for it, called TLS-SRP, but unfortunately no browser supports it.

Nit: I think you mean hashing, not encryption.

Though, my bank uses a dual-password setup where the first password is required in its entirety and a few letters of the second password are required. I suspect this is stored by using a (hopefully memory-hard) salted key derivation function/password hash function (such as Argon2 or scrypt) to derive an encryption key from the first password, which is then used to decrypt the second password.

At least, that's the way I'd design the system to minimize consequences of database compromise. Users are often not creative and often use related passwords. You'd want all of the stored information about the second password to provide clues to the first password only if the attacker had already cracked the first password. Hashing all of the permutations really blows up storage space and DB I/O.

Hashing in this sense is one way encryption.

Cryptographic literature often mentions one-way functions, but I don't think I've ever seen the phrase "one way encryption" in a cryptographic paper. It's not a phrase used by cryptographers, except rarely to describe encryption using trap door one-way functions such as RSA.

You can, but I’d assume they don’t. Plain text all the way!

Ok, yes. Encryption could work, but encrypted passwords aren’t much better than plain text ones.

Possibly using this? https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

I think a lot of implementations don't do anything clever and just have a fixed set of combinations they use each time, so the number of stored hashes is smaller.

I thought about something similar to Shamir's Secret Sharing, polynomial fitting over a finite field, but in this case, information theory is working against you.

With Shamir's Secret Sharing, you start out with your secret expressed as a finite field element, and pick N-1 polynomial coefficients uniformly randomly from your finite field, and give M different participants values of the polynomial evaluated at different points. Information theory shows that having at most N-1 points on the polynomial still leaks no information about F(0). It's as secure as a one-time pad, and in the degenerate case of N=2 over a Galois field, is in fact a XOR-based one-time-pad. The amount of entropy added at generation time is greater than the amount of entropy in the secret.

In this partial password case, you'd want the "shared secret" to be a single value, and construct a polynomial such that, say 4 field elements, would always be sufficient to recover the same "secret". You're running the algorithm the wrong way, and unless you're forcing a password on the person, those letters are actually low-entropy instead of maximal entropy field points as in Shamir Secret Sharing.

I really don't see a way to use polynomial interpolation in this way without leaking entropy. I thought about using something similar to Schnorr threshold signatures[0] to solve the information leakage, but then you end up storing one elliptic curve public key per password letter, and the private key for each public key is a single letter, so trivial to bruit-force.

[0] https://eprint.iacr.org/2020/852.pdf

There are browser plugins and script-injector-modifiers that help with this. "Don't Fuck With Paste" is one I use.

But yeah, that's infuriating.

I recently got an OnlyKey.

It plugs in as an HID so that passwords appear to have been typed in, not PW managed.

Useful little thing, it seems too good to be true.

OnlyKey looks interesting. A few things make me skeptical though: It only supports 24 accounts, which is two orders of magnitude fewer than I have in my password manager. And the hardware design doesn't look super convenient or durable. I bought a YubiKey a few years ago, and kept in on my keychain, and before I had even used it a dozen times, the entire thing disintegrated and became unusable.

Edit: I'm also a bit uneasy about securing access to all by accounts by one single PIN that can be used to unlock a physical device that is easy for someone to steal unnoticed.

This means the password manager can’t check it isn’t entering your credentials on app1e.com

PeopleSoft ? (Poephol-Soft in dutch/afrikaans) as we used to call it !

What, is "password managers are insecure" really a thing?

Yup. And they are, technically, because if someone has that one login and password, they can access all your accounts.

But it turns out that keeping that 1 login and password in your head and trusting the rest to your password service (especially if you let it make random passwords) is way more secure than what people do if they have to try to keep them all in their head.

So it's about relative security. Both sides are correct, in their narrow views of the situation.

I believe security should optimise for the threat levels on the order of importance. No.1 is password reuse, which is what password managers solve.

It can be. Single master password, if leaked or otherwise getting into the wrong hands, gives access to all your auth details. This is part of why I keep to a desktop based password manager rather than an online one.

But it depends on your threat model and attack surface area/shape. A strong password on a post-it on your monitor is stupidly insecure locally, but far more than just having a weak password if you consider only non-local (to the user) attacks (neither that site hacker in far-off Hackyoustan nor his pet bots can see the post-it, but could try brute force a short easy to remember password).

Yes, if not explicitly then by their actions definitely. E.g.: there is only a single bank in France that hasn't switched to a stupid 6-8 digit system where you have to click buttons that appear in random order. Before then they often disabled autofill on passwords (luckily that could have been easily bypassed). They incessantly re-invent the wheel for 2-factor auth and so on. I find it very curious why banks of all institutions are those with the worst security.

Not sure if that's the bank you're talking about, but FYI Fortuneo lets you use a normal password.

Yep, Fortuneo is the one still having sane security. There might be others but when I was bank-shopping I haven't found one.

Sane security would be using a one-time password 2FA in my opinion, but yes, it's the only one I know with a non-crazy login method.

Bnp paribas have had this on their online accounts for at least a decade now

Hardly surprising considering how long they clung to ‘secret questions’.

But they (or their bosses) will care if credit card details can't be auto populated. Typically anything that slows down the user from paying gets fixed pretty quick.

But you're right, browsers would have to become picky on saved credit card auto populate to force a change.

Yeah but people that use password managers are TINY fraction of users.

All modern browsers now ship with a password manager (Firefox is currently rolling out CC filling country-by-country) so that number can't be too low.

oh yeah after reading the OP i totally wonder why

> I can't offer a general solution, but if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing.

Unlikely. The password managers would just lose users.

I've even caught myself being annoyed at 1Password when it doesn't work while the cause is obviously the website doing some stupid thing.

I wonder how 1Password works on this problem though, do they just accept the crap and keep working on their guessing magic or do they also invest in standardization?

I always find it very interesting how the 1Password X (the standalone extension) team seems to work half the day just to fix some random website. At least their „fixed“ section of the release notes consists usually of a listing of websites where autofill does (did) not work [1].

[1] https://app-updates.agilebits.com/product_history/B5X

One solution could be to very prominently highlight auto-filled fields especially if the standard auto-fill attributes are missing. That might at least help some users avoid submitting info they didn't intend to.

Some password manager allow you to config those parameters yourself but I guess that would not work in this case.

Hopefully hardware tokens can help us get rid of passwords soon.

1Password does do something to help combat the problem that OP had... they change the background color of any input that they auto-filled to be blue. Blue is a weird color for most sites and it should stand out to the user (generally in a field of white) after they auto-fill a form. I have had 1Password fill in the wrong inputs before and only noticed it because of this feature. I noticed an input higher up on the checkout form had changed blue. It caught my attention and allowed me to fix it manually.

Now in this situation, it looks like Substack's UI is to blame. The secret form field appears to be heavily modified from its original form state, probably masking the blue background that 1Password attempted to give it.

1Password is in a difficult situation here. If the autofill doesn't work (because the developer of the website they are filling, uses non-standard naming), then users will blame 1Password for "not working", not their browser or the website developer. 1Password therefore has to make it work with as many forms as possible around the web, most of which are built by lazy developers trying to throw up a website during a hackathon, or from a developer that learned to code from a 1 hour youtube video. It's a tall order, from their perspective, to try to make this work with as many forms as possible, while having the fewest (ideally none) false positives.

The one thing I can recommend for anyone who uses any password manager, is that before you click submit on a form that you used auto-fill for, you always look over the entire form again. Now in OP's case, I could see how they could have easily missed the extra amount (again, Bad UI substack), but this is general rule that anyone with a password manager should follow. Double check everything before you submit.

> if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing

This is a market problem. All but the last password manager to do this would go out of business, due to reduced utility vs alternatives.

> Somehow this kind of nonsense has become culturally acceptable in the software industry.

This seems to be particularly common in the web development world, even in the fundamental tech upon which the web is built. Missing the closing tags in your HTML? The browser will just guess where it should be for you. Missing a semicolon in your Javascript? The interpreter will just guess where it should be for you. Invalid CSS? The browser will just silently ignore it. Illegal comments in your JSON? Most parsers will just assume you meant to ignore those lines.