93

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?

  • 29
    All scenarios are possible. – user45139 Sep 17 '15 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 '15 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? – MarkS Sep 18 '15 at 15:45
  • 11
    If I experienced just what you describe, I would stop using Bluehost ASAP. – Octopus Sep 18 '15 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 '15 at 18:38
135

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 '15 at 15:19
  • 73
    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... – Panzercrisis Sep 17 '15 at 16:34
  • 36
    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 '15 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 '15 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. – Gustavo Rodrigues Sep 17 '15 at 19:18
13

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 '15 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. – WhiteWinterWolf Sep 19 '15 at 9:10
8

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!

  • 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 '15 at 20:15
  • 2
    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 '15 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 '15 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 '15 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 '15 at 19:04
6

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. – Steve Jessop Sep 18 '15 at 0:44
2

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.

2

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 '15 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 '15 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 '15 at 10:09
1

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:

*********ange

Or this one:

****1994

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 '15 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 – GameDeveloper Sep 23 '15 at 11:04
  • @Selenog and at this point the downvote should be revoked? – GameDeveloper Sep 23 '15 at 11:13
1

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 '18 at 23:24
-2

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 '15 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. – Steve Jessop Sep 18 '15 at 0:42
  • 2
    The arbitrary number of additional characters really adds to the absurdity of this answer. – underscore_d Sep 18 '15 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.