I just phoned the customer support number for my ISP for the first time and was surprised to be asked the fourth and fifth characters of my password, specifically the one I used to log into my account on their website, not a special password for use over the phone. The fact that they know what the fourth and fifth characters are shows that they are not hashing the password.

I believe the GDPR requires them to store the password securely, and if they're not hashing it then I'm sure it can't be considered secure, so should I report them to someone?

The only thing that makes me think this might be acceptable is that it's common for organisations to ask for certain characters of a password over the phone. I think they normally set up a different password specifically for this though, rather than using the website login.

  • 33
    Perhaps they stored the fourth and fifth characters of the password when you set it. That would also reduce the security of your account, but not by as much as storing the entire password in recoverable form.
    – phoog
    Commented Jun 11, 2019 at 15:38
  • 13
    Regardless of what the legal side of this is, you should report them to plaintextoffenders.com. Even if it is encryption or what Phoog mentioned, its pretty bad and they should be pressured to switch Commented Jun 12, 2019 at 0:14
  • 5
    There are various technological approaches to this which don't involve the password being in plain text or even protected by reversible encryption, so its entirely possible their implementation meets the GDPRs requirements.
    – user4210
    Commented Jun 12, 2019 at 1:10
  • 3
    – Joelty
    Commented Jun 12, 2019 at 6:26
  • 8
    You have no proof whatsoever that they store the password in a form different from a hash. When you change your password they can easily create two hashes: 1) the hash of the whole password and 2) the hash of just the 4th and 5th characters and the operators can check the 4th and 5th character using this second hash. Sure, this hash can be easily brute forced independently of the load factors of the hashing function but your assumption that they must store the password in a form different from a hash is simply false Commented Jun 12, 2019 at 10:07

4 Answers 4


The GDPR does indeed require that the password be stored "securely". It does not specify the technology which must be used for that purpose. Hashing the PW is a common method, and should be sufficient if properly implemented (strong hash function, use of salt, etc). But other methods of securing the password might be sufficient. Encrypting the PW rather than hashing it, so that an authorized person could decrypt it temporarily might be OK. Or perhaps a security app can separately retrieve only the specified characters of the PW through some sort of encryption. Or perhaps the ISP is not using proper security. In the case of Knuddles in the linked news story, an actual breach occurred which led to the poor security being reported.

You could send a report to the appropriate national Data Protection Authority.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – feetwet
    Commented Jun 13, 2019 at 19:11

Well, you may be right (probably), yet then again, you may be wrong...

As David Siegel mentioned, they may have encrypted the password and have authorized support personal decrypting them up-on support calls for authentication purposes...

What you can do is to submit a Data Subject Access Request focused on your Password and HOW they handle it in a secure manner... plainly explain this same doubt that you have posted and ask for them to explain to you HOW do they ensure the Security of your Data, namely the password (in a manner that they are not forced to disclose any "business secrets") but you are still comfortable and reassured with the feedback.

If the answer is "far from satisfactory" use their feedback along with your initial query to compile and submit a structured complaint to your Supervisory Authority so they may be "audited".

  • 14
    @only_pro Isn't this mixing up hashing and encryption, most of the time when you encrypt things you expect people with a key to decrypt it Commented Jun 11, 2019 at 22:15
  • 9
    @only_pro encryption is, by definition, a reversible process. a secure hash is not encryption, precisely because it is not reversible. A hash is not the only way to make a password 'secure" as required by the GDPR, although it is a very common way. Commented Jun 11, 2019 at 22:45
  • 4
    Note that reversible encryption doesn't mean that the support person can see your passwords. It means they can check characters in your password; for that their system has to decrypt the PW but doesn't have to expose it. That makes for a smaller vulnerability than showing the PW to support staff
    – Chris H
    Commented Jun 12, 2019 at 9:27
  • 3
    This answer is incorrect in that it does not understand best practices for passwords. Best practices for passwords are to hash them, not symmetrically encrypt them. A Properly hashed password cannot be reverted to its plaintext form. I gave a Stack Overflow answer that goes into detail on this here. stackoverflow.com/a/4435888/16587 If someone can decrypt your password, it has not been hashed and that is a security vulnerability waiting to happen. Commented Jun 12, 2019 at 13:59
  • 3
    @GeorgeStocker the fact that hashing is irreversible and encryption is reversible does not make this answer incorrect. The question wasn't about best practices.
    – barbecue
    Commented Jun 12, 2019 at 14:52

It's possible that they're storing a hash of the entire password, and in addition storing a hash of just characters 4-5. If they always ask for the same two characters when you call in, this is more likely.

The 4-5 hash is a small security vulnerability, since it would be much easier to crack than full passwords, and then that can be used to reduce the amount of work needed to crack the corresponding full password. Or if someone cracks the small hash, they could call into customer support, convince the rep that they're you, and potentially get them to reset the main password (tech support generally needs to be able to do this if the customer forgets their password and also loses access to the email address used to reset it).


Focusing on the actual problem, your ISP needs to have a way to authenticate its customers (a 'password') when they phone customer support. This means that such password needs to be told to the support agent. Of course, it would be a bad idea to tell them your password, so apparently they decided to setup their system such as:

  • Store the password unhashed internally
  • Their agents can't view your password¹
  • Their support software does have access to the plaintext password, and ask for a couple of characters (different ones each time) in order to authorize you.

This way, the person servicing your call will, at most, know the two characters that you provided.

Compared to giving out your full password to them, it is more secure. Maybe they even eg. store in plaintext² half of the password and hash the other half. It would be desirable that they supported having a different password for phone support than their website (perhaps they do but you would need to set up such "phone password" separatedly?) but once you consider the additional requisite of customer support authenticating you through phone, it's not that unreasonable, unlike the case when you are authenticating directly to their website without any middle-men.³

‏One would still expect that they implement other sensible additional measures. Anyway, don't use any sensitive password. It is best if you use a password manager with a random password only used there.

It is also a good idea to follow the suggestion of Rui Freitas Serrano and ask them about their authentication process and how they protect the security of your account.

¹ So we hope, at least.

² Plaintext and reversible encryption are mostly equivalent here

  • 1
    "Store the password unencrypted internally" -You have no evidence of that. Do you mean "Store the password unhashed internally" ? (It's a very different thing.) Commented Jun 12, 2019 at 8:32
  • 1
    @MartinBonner so much talk of encrypted passwords above. You are right, of course. Fixed.
    – Ángel
    Commented Jun 12, 2019 at 9:48
  • 2
    A system in which they ask for different characters each time would be even worse than just asking for the same ones each time since it would reveal more and more of the password over time (making it far less secure) and eventually reveal the entire thing
    – Kevin
    Commented Jun 12, 2019 at 22:53
  • 1
    @KevinWells If it always asked the same two characters, those two characters would be password-equivalent, and available for any support operator that handled them once. OTOH, varying the characters means the same roque operator would need to assist the same user multiple times while keeping track of the previously obtained characters, which is sturdier (specially taking into account they will be continuously handling password characters with no sense, so they will probably not remember them).
    – Ángel
    Commented Jun 13, 2019 at 1:27
  • 1
    @Ángel I can think of a number of ways that would be better. For example, they could send one time use verification codes to the customer's email or phone (the one attached to the account), that shows that the person calling is the account holder without involving their existing password
    – Kevin
    Commented Jun 17, 2019 at 15:57

You must log in to answer this question.

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