I have some domains/websites as well as emails with Bluehost. Every time I need support, they need the last 4 characters of my main password for the account. They cannot tell me how they store the password, so I am intrigued in how they could safely store my password(s) and still see the last 4 characters. Do they see the full password in plain text?
There's several possibilities.
They could be storing the full password in plaintext, and only displaying the last 4 characters to the support person.
They could be hashing the password twice. Once hashing the full password, and again with just the last 4. Then the support person types in the last 4 to see if it matches the hashed value. The problem with this is that it makes it easier to brute force the full password since the last 4 characters are in a separate hash, reducing entropy.
They could be hashing the full password, and storing the last 4 in plaintext. Obviously this makes it much easier to brute force the password if an attacker gaining access to the password database knows the last 4 digits.
Something else where the last 4 characters are stored in some way that's discover able, such as encryption that Mike Scott mentions below. If the secret to unlock the 4 characters can be discovered, this is as bad as plaintext.
All scenarios are very bad, and greatly reduce the security of the system. It's not possible to know which scenario they're using, but each of them shows a lack of consideration for security breaches. I'd advise caution if this is a site where you care about your account being breached.
It is always hard to answer such questions since we are not in Bluehost's secrets, so we can only guess and make suppositions.
However, the behavior you describe remains possible without storing any clear form password:
- When you create a new account or reset your password, the password is sent to the server, most likely in clear form protected by TLS,
- The server will then generate two different hashes for the same password:
- The first hash takes your full password and is used for usual authentication,
- The second hash takes only your password's four last characters,
- When you contact their support team, you tell them your last four characters, they type them on their software, then their software will internally calculate a hash, check it and display the result to the support technician.
BlueHost advises reasonable rules for strong passwords, so they probably employ at least one person who knows what he's doing.
Assuming such, BlueHost may be using an implementation of Shamir's Secret Sharing or a variation on that theme. Shamir's is theoretically secure, so I wouldn't immediately jump to the conclusion (as other answers have) that any scheme doing this is inherently less secure.
On the other hand, implementing Shamir's is non-trivial, so any of the other answers could equally apply. Since security is ultimately about trust, if you feel insecure with this scheme, I suggest you find another provider!
I cannot tell you exactly how they store the password. But from your description of their process we can show that the password must be stored in an insecure way.
I am assuming that when they are asking for the last four characters they will actually be able to verify the correctness of what you told them (in other words, they are not simply bluffing).
This means they have data which will allow them to verify the characters you told them in a short amount of time. The same data can be used in a brute force attack to break the last four characters of the password. Four characters is certainly too short to stop a determined attacker.
Once the attacker has the last four characters another attack can be mounted on the earlier characters. For this brute force attack the last four characters of the password add no security, so at best you have the equivalent security of a password four characters shorter than it actually is.
It might be possible to work around the vulnerability by choosing a secure password and then append four additional characters chosen completely independent of the password chosen at first. This will be secure if they can only verify the last four characters and not a suffix of arbitrary length.
If they are in fact able to verify a suffix of arbitrary length and not only those of exactly four characters, the password storage would be even weaker. That would be about as insecure as storing it as plaintext, and in that case you cannot work around it by choosing a stronger password.
I do not think this is likely, merely possible.
Every time OP needs support, they ask for the last 4 digits of his password. They salt and hash it and store the salt and hash and enough information to reconstruct the support in a special support table.
Then when OP logs in (with the full password), they can review the support table and calculate the hashes. Then they commit the verified "supports" and repudiate the falsified "supports".
This of course assumes that
support is something that can be committed or repudiated at a later time
the process of asking for the last 4 does not leak information (someone asking you for the last 4 does not qualify because we can not reliably wipe their memories).
I can not imagine a situation where this would make business sense. But if it did, I think I would issue my users a special 4 digit "support" password instead.
They can see the full password? Yes it is definitely possible they can guess the password (if the 4 last digits are a date or parts of a word. If the password is hashed in full knowing 4 digits is enough to do a brute force attack or even trying to do a heuristic on the hash function to see how 4 digits propagate back reducing by much the range of possible passwords.
Guess this password:
Or this one:
It is also possible they are hacker and exploit the customer support API (if any) to access users information, that task is even made easier by knowing 4 digits.
They should not do it, in no case is giving part of the password to a stranger a good option even (ESPECIALLY, if after he get fired he may try to harm users, and there are many historical examples) if it is part of customer support.
A customer support should have no way to access the original password and should act through an ad-hoc API to prevent doing bad things (still support should not be able to access the full data).
Also, if customer support have to ask 4 digits of the password, you cannot email users with warnings like "never give your password because we don't ask that" because you are actually asking that and training your users to give personal details may help them to get caught by phishing emails.
If they really want to check user autenticity they should use stuff like SMS codes, secret questions, or just a email-sent keys.
Still, I think it is much cheaper sending an email or a SMS than paying 1-2 minutes someone doing the same thing (unless she/he's really underpaid person).
If a service really need to check user identity someone for something important I would probably use a webcam stream from wich a operator can see the user face, and then ask it to do specific actions (like writing a word on paper and show him back) in order to prevent someoneelse using a recorded video).
This of course will not be liked by users because of privacy ^^
As others have said, there are many ways that this provider can go about protecting the 'last four digits' of your password. However, ANY time you broadcast even a portion of your password, you're opening yourself up to getting your account compromised. One of the things that no one seems to have mentioned is the last 4 digits of your password that you type into the chat log probably don't get encrypted. Obviously, chat logs need to be easily accessible. Even if you follow a basic password complexity rules, you've just reduced the effective length of your password by 4 characters. Now imagine if that's a password you use in other places with lighter security (which unfortunately, a lot of people do).
TL:DR This is a ridiculous practice and I would stay away from them at all costs