No Stupid Questions

I'm assuming they're plain text. There's is no perceivable way they can only use those data points to to figure out which hash it is. Unless of course they're using their own "hashing" function which isn't secure at all since it's probably reversible.

I have never heard of anything secure doing that. Assuming they have taken security steps, it would mean they recorded those characters in plaintext when you set your password, but that means that at least those characters aren't secure, and a breach means some hacker has a great hint.

When the hashing occurs, it happens using the code you downloaded when you visit the site, so it's your computer that does the hash, and then just the hash is sent onwards, so they can't just pull the letters out of a properly secure password.

A secure company would use two-factor authentication to verify you above and beyond your password, anyway, since a compromised password somewhere else automatically compromises questions about your password.

I’ve noticed a few companies ask for specific characters of my password to prove who I am (eg enter the 2nd and 9th character)

They what?!

This is a huge red flag and should not even be possible for your primary password, if they are following basic security principles. Are you sure this isn't a secondary PIN or something like that?

Do they always ask for the same characters? I'd imagine they could hash the password as well as saving only the 2nd and 9th characters as plaintext. Still a bit of a security risk but not nearly as bad

Good question. A lot of banks in Europe use this type of setup, where it will ask you for 3-4 characters of your pin/password, both to login and to confirm transactions. I always thought it was weird but never thought about the security implications.

I always figured they checked the plaintext locally before hashing and sending it to their server, but I don't really know.

One of the main differences between hashing and encrypting is that encryption is réversible by some means, while hashing isn't. The irreversibility is what makes it so ideal for storing a password in a way that definitely can't be used to get the original password back, even if someone steals the whole database with the passwords in it.

Those companies that ask for specific characters might be encrypting the passwords, but they definitely aren't hashing them.

They could hash pairs of characters on password creation and store those. Seems like more data points to guess the original password, but maybe the math is hard enough it doesn't do much.

There's a security exchange thread on it here

It looks like there are certain kinds of algorithms you can run that give you this property.

Also, I've seen this when you have an alternate form of authentication like a password you type in full, or an existing session token. In those scenarios, you could probably use some sort of symmetric key encryption to encrypt the secondary password with the primary password / session token in such a way that you aren't storing the key and can't decrypt it, but that you can check specific digits on command.

Full-stack dev here, not necessarily in answer to OP’s question, but in my experience it is a pretty standard practice that when you log in to a service, the web page sends your unhashed creds to the server, where your password is then hashed and compared to the stored hash. Via HTTPS/TLS/SSL, this is a reasonably secure practice since the creds are still encrypted while in transport. Hashing is a computationally expensive process that (before the advent of WASM) wasn’t really feasible to do on the client side.

This is typically used for a secondary authentication factor in most instances, such as a service ID number after you've already provided a username, and entered at the same time as a password.

It is not possible for them to securely be storing the password yet being able to retrieve individual characters at the same time.

The way I’ve seen this done before, it was not for a password, but for a token entered after the password was entered. No, the token is not encrypted, and therefore it would not be secure for the service to use it as a password.

The most secure way this could happen is them storing the specific character separately. It reduces security of your password if that plaintext character is compromised but you could still store the rest of the password securely.

You could even salt and hash the one character with a large salt to keep it behind a one-way function, and then the agent would need to enter it and confirm via the system, but that would reduce any downside of the one or two characters being compromised.

It's weird either way though.

I’ve only seen this as a second factor after entering a full password. Although it has mostly been replaced by actual 2FA now. Last time I remember this type was on the uk gov student finance website