97

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?

rhymsy
  • 1,212
  • 1
  • 10
  • 15
  • 31
    All scenarios are possible. –  Sep 17 '15 at 15:29
  • 4
    This is with a reputable webhost, so although we can't know for sure that it was done in a smart way, we can (probably) assume they're doing it at least somewhat safely. There really isn't a safe way to do this, though. – Jon Sep 17 '15 at 16:43
  • 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 04:07
  • 1
    @emory Depending on how much security theater, there's a chance that deliberately giving them the wrong 4 digits might result in the asker's account getting locked. – user253751 Sep 18 '15 at 04:34
  • 1
    @immibis good point. call them and ask for support using another user's credentials. Then when they ask for the last 4, make up something. If they proceed to give support, there is a good chance they do not have a system for last 4 verification and asking for it was all for show. – emory Sep 18 '15 at 04:53
  • 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? – Monkey47 Sep 18 '15 at 15:45
  • Sounds like I would treat the last four digits of my password as effectively a two-factor authentication PIN and construct a password that was strong *without* those last four digits. IE, `correct horse battery staple 7684` as a password. – Joe Sep 18 '15 at 20:59
  • 11
    If I experienced just what you describe, I would stop using Bluehost ASAP. – Octopus Sep 18 '15 at 21:58
  • 3
    @Chipperyman, we most definitely cannot assume anything. They might have a large customer base and also be giving away credit card numbers, you just don't know. – Octopus Sep 18 '15 at 22:00
  • 2
    @emory how on earth would asking for part of your password, "be for show"? The only thing that shows is their complete incompetence about security. – Octopus Sep 18 '15 at 22:01
  • 2
    @Octopus in the same way that taking off your shoes at the airport protects aviation, reciting 4 digits to a serice rep who may or may not be able to verify them may "protect" bluehost. Certain users equate incovenience with security. Give them what they want. – emory Sep 18 '15 at 23:23
  • @emory, no, absolutely not. its not inconvenient, its bad security practice. – Octopus Sep 19 '15 at 06:44
  • @Octopus no one is suggesting that it's a good security practice. – Rein Henrichs Sep 19 '15 at 19:34
  • 4
    The last four characters are of course either "3456" or "w0rd" or "aple" – Hagen von Eitzen Sep 20 '15 at 12:59
  • For all those preaching this is an "impossible bad descision" - From a business perspective it can be a totally valid use-case. If their Password DB is hacked, it will be bad for the company. Every User will be informed "security breach, please change your password" - if they stored 4 digits unsecurely, passwords will be cracked faster. So the reputation damage will be a bit higher, but since this is a low probability high risk scenario anyways, the overall impact on risk-budget may be really small. And the benefit of users not forgetting their extra-code may be bigger. – Falco Sep 21 '15 at 13:41
  • 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
  • 2
    @Mansav Still, the only way that could work is if the password is stored un-encrypted somewhere. – Daniel Sep 22 '15 at 13:02
  • 3
    @Daniel technically they could have 2 hashes, one for the whole password and one for the last 4 characters. It would still reduce security but not as much. – Murphy Sep 22 '15 at 14:56
  • They could storing the last 4 characters as a separate value in the database (in the clear or hashed) - which makes it easy to verify. – whoami Sep 23 '15 at 12:23
  • They could just multiply all the values then store them in plain text. Of course it means many passwords will be valid, but I think this is a good compromise. Something other than multiplication may have been used to get a hash will many collisions. – jkd Dec 05 '16 at 09:54

10 Answers10

139

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.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • 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
  • 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... – Panzercrisis Sep 17 '15 at 16:34
  • 3
    I just checked the password change form on my Bluehost account. Unfortunately, the website will let you use passwords as short as 8 characters, which means that those last four digits can dramatically weaken some passwords. (I'm guessing that for sufficiently long passwords, letting the last four characters be discovered doesn't reduce your entropy enough to be a practical concern?) – Kevin Sep 17 '15 at 16:37
  • 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 '15 at 18:06
  • A good scenario: The password is split. The first characters are hashed with a salt and the last 4 are hashed with another salt. – Ismael Miguel Sep 17 '15 at 18:30
  • 6
    @Ismael: That still reduces the time to break from `O(2**(n+k))` to `O(2**n + 2**k)` ... which is **really really bad**. About as far from "a good scenario" as you could imagine (admittedly still better than storing plaintext) – Ben Voigt Sep 17 '15 at 19:13
  • 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
  • @MikeScott How else would you store a hash of 4 characters? I though it was implied that it is supposed to make the operation as slow as possible. – Ismael Miguel Sep 17 '15 at 19:18
  • 2
    @IsmaelMiguel You wouldn't architect your system in such a way that you were storing cryptographic hashes of four character strings at all -- there's no right way to do it, so just don't do it. – Mike Scott Sep 17 '15 at 19:29
  • 6
    @MikeScott Fine fine fine fine fine fine fine fine fine fine fine. But how would you protect a 4-char pin? – Ismael Miguel Sep 17 '15 at 19:34
  • 5
    Notably, the least secure option is also the easiest one, and hence unfortunately the most likely. – Superbest Sep 17 '15 at 21:46
  • If I understood it correctly, they probably only allow you to "enter" the four digits password through telephone. I'm wondering if that significantly reduces security because one cannot make thousands attempts per second through voice-over-telephone :). The "second" password could be stored on a database with read-only access. I'm wondering what the security implications would be for such scenario. – Willem Van Onsem Sep 17 '15 at 22:27
  • 2
    If the last 4 characters are stored as a check digit (similar to the high collision hash described above), it would not significantly weaken the hash of the actual password, which can be securely stored. – March Ho Sep 17 '15 at 23:12
  • @Kevin: if the first n-4 characters of the password constitute a "good enough" password for some purpose and the last 4 give no clue to the others then sure, revealing the last 4 characters doesn't cause any problems for that purpose. So for example if you randomly generated the password using your password manager, then it may already have 4 characters worth of overkill and if not then adding 4 characters beyond what you'd usually use will make sure. – Steve Jessop Sep 18 '15 at 00:29
  • 2
    ... but this is still silly by the provider, since they haven't explained the consequences to the questioner. They could instead have asked for a separate 4-character support "password". Of course if you do that there's still a risk users will give you 4 characters from their main password, it's not straightforward to convince them otherwise. So you could generate it for them, but then they won't remember it, etc. Or you could login and hit a button to generate a temporary support code, but that doesn't help people whose support problem is they're locked out of their account... – Steve Jessop Sep 18 '15 at 00:32
  • 3
    @IsmaelMiguel You have to store the pin in a hardware TPM. That's what banks do. – Navin Sep 18 '15 at 05:27
  • @Navin Aren't those read-only? Besides, how would you change the pin of, say, your account? (In my case, instead of a credit card, I have this book that the ATM reads, like a giant magnetic-band card. How would it be stored, in your opinion?) – Ismael Miguel Sep 18 '15 at 08:10
  • Some banks are issuing credit card with pin code that physically block access to the chip after some limited number of tries. They _could_ have one such chip per customer, and store securely the last 4 characters in it. They probably don't though. – TonioElGringo Sep 18 '15 at 11:50
  • @CommuSoft, brute force attempts are never made through the intended interface anyway. It would be way too slow. The trouble would come when/if someone got access to the database. Storing it separately from the main hash doesn't help, and neither does making it read only. – Chris Murray Sep 18 '15 at 15:06
  • @ChrisMurray: I know that. About read-only: I made an error, what about a database with write-only access for the connection through the server. This would create an additional barrier to circumvent. – Willem Van Onsem Sep 18 '15 at 15:09
  • @CommuSoft, Can't make it write only, as the support system needs to be able to verify the given password against it. – Chris Murray Sep 18 '15 at 15:11
  • 1
    @ChrisMurray: I mean that the database server has two connections: one to the (webserver) that is write-only. A second one attached to the "intranet" that can manage to read the content. Evidently it is possible to try to hack the access rights, but it makes it at least one step harder. Evidently a device that only has a way to write data only increases the entropy in the universe. – Willem Van Onsem Sep 18 '15 at 15:17
  • What if I has password abcdef. They hash all but the last four characters (ab) and then hash the last four characters (cdef). This mean there's two hash that could be totally independant with different salt. When you log it check both hash, but customer service checks only one. – the_lotus Sep 18 '15 at 15:47
  • 3
    @the_lotus That's possible too, and equally as bad. There's many different ways to do it, but all of them are going to compromise the hashing process. I don't know of any way to do this in a way that doesn't compromise the security, and it may even be impossible to do so unless you rely on something like a TPM. – Steve Sether Sep 18 '15 at 16:15
  • 1
    @CommuSoft I run a business that processes a lot of transactions and that's exactly what I do! The webserver can only *write* to the database that stores SSNs, bitcoin private keys, etc. Only someone with physical access can *read* from the database. – Navin Sep 18 '15 at 19:53
  • 1
    "All scenarios are very bad" Please highlight this part of your answer. Make it as black as possible, as large as possible and as uppercase as possible. – Octopus Sep 19 '15 at 06:43
  • 2
    Another option for your list is that it could be done using an HSM + symmetrically encrypted passwords. Correctly implemented this isn't insecure (it's what many/all banks do with card PINs for example.) – Rory McCune Sep 19 '15 at 09:54
  • 5
    @GustavoRodrigues This would also increase the likelihood of a false positive identity confirmation. – Rein Henrichs Sep 19 '15 at 19:38
  • 1
    I've also seen another approach (sometimes used for certificates) - all the PINs would be stored on a seperate computer, connected only through a simple serial link. The only operation possible is "Send PIN -> Read Success/Failure". Unless someone gets to the computer *physically*, this is as safe as it gets. And we all know what you can do with a computer once you get to it physically :) – Luaan Sep 22 '15 at 11:50
  • Remember when discussing brute-forcing the 4 characters, they're being given verbally to a service representative; not being tried thousands at a time automatically. – Daniel Sep 22 '15 at 13:06
  • @Daniel We're assuming that the hacker has penetrated the system that the service representative uses to verify the four characters, most likely by getting hold of the underlying database. And so the speed of brute-forcing is only limited by the speed of their hardware and the difficulty of the algorithms that are used. – Mike Scott Sep 24 '15 at 07:03
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.
WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • 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 09: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!

bishop
  • 314
  • 2
  • 9
  • 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](https://web1.tcdsb.org/CCRFProduction/images/Strong%20Passwords.pdf). 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.

kasperd
  • 5,402
  • 1
  • 19
  • 38
  • 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 00: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.

hogarth45
  • 243
  • 2
  • 9
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.

emory
  • 1,560
  • 11
  • 14
  • 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 ^^

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

Falantar
  • 11
  • 1
  • 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
1

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.

Alex AO
  • 11
  • 2
-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.

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