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?

  • 31
    All scenarios are possible.
    – user45139
    Sep 17, 2015 at 15:29
  • 27
    The next time you need support give them some other 4 digits. As @Begueradj said all scenarios are possible. This includes security theater.
    – emory
    Sep 18, 2015 at 4:07
  • 8
    @immibis, what you're suggesting is that any person can get another person's account locked by simply calling up and giving the wrong information?
    – Fauxcuss
    Sep 18, 2015 at 15:45
  • 11
    If I experienced just what you describe, I would stop using Bluehost ASAP.
    – Octopus
    Sep 18, 2015 at 21:58
  • 16
    As a former employee of Bluehost, I can tell you that they do not know the whole password. There is just a box that the agent types the last four digits of the password into and then the system will check it against the password it has on file. If it matches, it will turn green and will be logged, if not, then it will turn red and mark the log as well. Even if they did know the password, everything the employee does is logged on the account and can then be looked at if anything is presumed to have happen. As for the storage of the password and the encryption, beats me, but I never heard of any
    – Mansav
    Sep 21, 2015 at 18:38

10 Answers 10


There's several possibilities.

  1. They could be storing the full password in plaintext, and only displaying the last 4 characters to the support person.

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

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

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

  • 13
    There's at least one more option. They could be hashing the full password and also saving the last four characters with symmetric encryption, so their software can decrypt them for the support person. Still bad, but not quite as bad.
    – Mike Scott
    Sep 17, 2015 at 15:19
  • 74
    And most good sites just come right out and say things like, "No one from here will ever ask you for your password." Meaning, of course, not even the last four digits... Sep 17, 2015 at 16:34
  • 37
    For all intents and purposes storing a hash of the last 4 is equivalent to storing plaintext too. With modern GPUs, you could brute force that space in no time.
    – mikeazo
    Sep 17, 2015 at 18:06
  • 10
    @IsmaelMiguel If you're hashing four characters, a salt won't save you. Assuming those characters are chosen from a set of 90 or so, there are only 65 million possibilities, and they can be brute-forced pretty quickly (unless they're using something like bcrypt with a work factor that's high enough to slow down operations to the point where the user notices the lag).
    – Mike Scott
    Sep 17, 2015 at 19:13
  • 28
    What if the last four characters are stored using a hash with high number of collisions, as it will be used for a simple one try verification? If this hash gets brute-forced it will generate many false results which will not help too much getting the full password. Sep 17, 2015 at 19:18

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.
  • Why would they use part of your password for this? That is what security PINs are for.
    – Octopus
    Sep 18, 2015 at 22:05
  • @Octopus: As said, we are not in Bluehost's secrets, so I can certainly not answer "why", I can only guess "how". And most probably even most Bluehost's employees could sincerely not answer "why" this system has been design like that: at some point in the time a few people, managers and project leaders, met together in a room and decided it was the best option, only they would know the exact pros and cons which were discussed during this meeting. Sep 19, 2015 at 9:10

BlueHost advises reasonable rules for strong passwords, so they probably employ at least one person who knows what they're 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!

  • 12
    Or that they were able to copy a list of reasonable rules from someone else. As it's sadly the case here. It's clearly copied from an old Microsoft page on passwords. They didn't even adapt it to fit their web, like the sentence «Password Checker is a non-recording feature on this Web site» (linking to Microsoft's Password Checker), or the discussion of blank passwords on different Windows versions (which is out of scope for bluehost).
    – Ángel
    Sep 19, 2015 at 20:15
  • 3
    Given those hints and that they don't even acknowledge that this content comes from a 2006 Microsoft article (would it have been so hard to say «Microsoft recommends the following tips for creating a secure advice»?), I highly doubt that they got permission from the copyright owner (Microsoft, probably) for copying it. But more important than the copyright violation (problematic enough for a company to be involved in), I think we can reverse bishop conclusion and come to the conclusion that they don't employ a single person who knows about this (or at least they didn't).
    – Ángel
    Sep 19, 2015 at 20:21
  • 3
    Which makes me even more wary of the security in this company. If they got things so wrong for an unimportant password advice, how can I be sure that they did things right for the big decisions? Especially after knowing about their already dubious practise of «using the last 4 password characters» for phone verification…
    – Ángel
    Sep 19, 2015 at 20:25
  • @Angel Nice research, and agreed: absent any other evidence of security-consciousness, I'm dubious of their motives and implementation.
    – bishop
    Sep 21, 2015 at 13:21
  • I don't see why this would be more secure. The only way this is more secure, is that you can provide the helpdesk person with a "part" that has to be social engineered out of them. Other than that, you now just brute-force the 4 characters with the known other parts until you get a secret that matches. Even in a situation where k+2 parts are needed, with k parts in the system, k helpdesk people and 1 secret only known by the client, you end up with at most k possible parts, which you can test against an other secret to figure out which part does not work, and thus must be the client's part.
    – Sumurai8
    Sep 21, 2015 at 19:04

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.

  • 1
    Indeed, if you can verify a suffix of arbitrary length then it's game over. It only takes 256 guesses (or less) to verify the last byte, then another 256 guesses to verify the last two bytes knowing the last byte, and so on until you know the full password in 256*n guesses. As you say, might as well be plain text as far as an offline attack on the stored hash is concerned. Sep 18, 2015 at 0:44

As you know a password should be hashed before it is stored, so you have got to ask yourself weather or not they are storing the last 4 characters for the purpose of verbal authorization and then hashing the password before storing, or they are just storing it plaintext.
I would guess the latter.


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.

  • And the stored-not-yet-verified "supports" still are an invaluable help to crackers, if they can be stolen alongside the hashed full passwords.
    – Ben Voigt
    Sep 18, 2015 at 22:27
  • @BenVoigt yes, brute forcing the last 4 digits is feasible so salting them does not add much value. Alternatively, if the attacker can observe which supports get committed or repudiated and the attacker can automate support requests without triggering a cutoff, then the observer can probably online brute force the last 4.
    – emory
    Sep 21, 2015 at 10:06
  • If the user makes a bunch of support requests and then forgets his password, either the support requests are committed or repudiated. If committed, then the attacker can make a bunch of support requests then pretend to as the user "forget his password". If repudiated, then the attacker can repudiate the real user's support requests.
    – emory
    Sep 21, 2015 at 10:09

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

  • 1
    Your answer is not answering the question. As a side note: I do not believe anyone here is advocating that such a system is best practice or even ok, but that is not really the subject here.
    – Selenog
    Sep 23, 2015 at 10:58
  • Now it is answering^^, I forgot to put that part because I was to busy writing the "additional part" of the answer. @Selenog Sep 23, 2015 at 11:04
  • @Selenog and at this point the downvote should be revoked? Sep 23, 2015 at 11:13

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

  • I would say it visible idiotism. Not visible idiotisms can be more problematic (for example, to allow the software development company what they hire to develop their customer relationship system, to see the anyways encrypted passwords before their encryption).
    – peterh
    Dec 20, 2018 at 23:24

I just talked to them today and they are still doing the same thing. The lady who helped me was not very knowledgable about encryption, but she did tell me what she did to validate my account. She told me she didn't have access to my account's password. But rather, she typed the characters I sent her into a prompt and then the system either validated it or not.

She told me that Bluehost does encrypts passwords. This makes me think that they are hashing the last few digits separately. Of course, as Steve said in his response above, even if this is the safest possible scenario where they ask you for a part of your password, it's still not great. The fact that they are hashing the last few digits separately decreases entropy and makes it easier to break the encryption.


They could be storing a hash of your whole password, plus a hash of the last four characters followed by 12 randomly generate characters. If the way they generate the random characters is as secure as the hashing process, this should be just as safe as storing your password by itself.

  • 3
    That would not work. How would you verify the last four characters by themselves?
    – kasperd
    Sep 17, 2015 at 17:48
  • 7
    Isn't this the same thing as salting the 4-character tail-password with 12 characters of salt? The problem is that 4 characters is so small that salt doesn't prevent a brute force search. More salt still doesn't prevent a brute force search. Sep 18, 2015 at 0:42
  • 2
    The arbitrary number of additional characters really adds to the absurdity of this answer. Sep 18, 2015 at 23:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .