I've asked them to clarify if they store them as plain-text, or if they're encrypted (and can be decrypted by CSA when needed) ... if it is plain-text, then I'll be taking my ~£80/month Virgin Media services elsewhere
Sadly, I believed you'll be talking to the wrong people there. They'll wrongly assume they're safe as houses and passwords are safe, but in reality you're speaking to the Marketing team who think replacing passwords with is safe.
I'm thinking of emailing them directly and asking the tech team.
And if they're not securely encrypted then I too will be taking my services elsewhere. My calls, bank details etc are logged. I don't want potential hackers knowing my parents number so they can target them and everybody else too.
Yeah.. My experiences with Virgin Media tech (both business and residential arms) are that all job titles appear to be encapsulated by inverted commas.
There's virtually no difference between the two. It doesn't matter if you're using the strongest encryption in the world: the system is automated, meaning it has the encryption key in memory so it can validate passwords, the support agents can read them, etc. An attacker doesn't care if it's plain text or if they have to decrypt them with an encryption key that's easily accessible to them.
If, instead, they were using a computationally expensive one-way function, a "password hash function", then an attacker would be able to get the digests it has produced, and maybe intercept a few live passwords as users log in, but they would not be able to trivially dump all the clear-text passwords wholesale. (Given the right password hashing setup, it is far too expensive to do so.)
It makes a lot of sense to use one-way functions for passwords: you only need to verify that a password is the same as the original (i.e. producing the same output when passed to the hash function); you don't need to know/remember what it is. There's no good reason for using encryption or storing them in plain text--"easier customer support" certainly isn't one.
> the system is automated, meaning it has the encryption key in memory
But it doesn't have to be in memory, or otherwise stored, anywhere near the bulk account data. If the encrypted password is transferred up the application layers to another physical resource that knows the key, and the passwords (encoded and not) or securely wiped from memory immediately after the comparison then this offers some useful protection over plain storage. An attacker would need to compromise both resources (the data store and the key holder) in order to get hold of credentials. For this to be meaningful the security of those resources and the communication between them must be very carefully designed and implemented, but it is wrong to say symmetric encryption is necessarily no better than credentials stored in plain form.
> There's no good reason for using [symmetric] encryption
As per my other post (https://news.ycombinator.com/item?id=6120089) the reason this is done is to permit partial password checking which is used to reduce the chance of successful reply attacks. Unless there is a way of achieving both aims the decrease in risk (and to a certain extent perceived risk) through stopping the replay attacks needs to be carefully considered along with the decrease in risk through using storage methods that make this replay protection impossible.
Of course security keypads as used by some banks (my mortgage provider uses such a system) is a better solution, if well designed and implemented without cutting corners, but there are cost and convenience implications there which may put off the companies (cost) or their customers (the inconvenience of having a small device to not lose).
> But it doesn't have to be in memory, or otherwise stored, anywhere near the bulk account data. If the encrypted password is transferred up the application layers to another physical resource that knows the key, and the passwords (encoded and not) or securely wiped from memory immediately after the comparison then this offers some useful protection over plain storage. An attacker would need to compromise both resources (the data store and the key holder) in order to get hold of credentials. For this to be meaningful the security of those resources and the communication between them must be very carefully designed and implemented, but it is wrong to say symmetric encryption is necessarily no better than credentials stored in plain form.
If the system can automatically verify a password, i.e. decrypt it, then an attacker can leverage that. You could design a system very carefully that might be invulnerable to memory injection attacks, might not be on boxes that have root escalation vulnerabilities, and which might be using a secure hardware security module--but why? You don't need to. Just use a one-way function.
> As per my other post (https://news.ycombinator.com/item?id=6120089) the reason this is done is to permit partial password checking which is used to reduce the chance of successful reply attacks.
Just add a PIN or something else that doesn't give you full access to the account. No reason whatsoever to store passwords people use on many other sites in what is, on 99.9999% of systems, equivalent to plain text.
There is a reply from someone called @Kaithar (https://twitter.com/Kaithar/status/361765029848170496) which says "actually, DPA does mean they need to be able to read your account password, the one setup for over-the-phone auth"
Surely that can't be true? DPA shouldn't give them the ability to read our passwords, only the ability to save DOB, payment type (direct-debit etc) so you can validate that. But not passwords.
I think they need to store your "memorable name" in plain-text for DPA purposes (so they can confirm they're talking to the account holder) but passwords for e-mail/billing etc. online have no need to be plain-text
Well, when I signed up online to their service I created a password. A few months later I went to login to figure out why our bill was so much but apparently the account wasn't working. I rang them, didn't remember setting a "phone password" so reset it then they said "Oh your password has been blahblahblah and blahblooblah before". But I'd only have used them online. And since I didn't remember setting it because they didn't offer me a "memorable question" reset. They just read my online passwords out to me.
Unfortunately it is very common. The approach a lot of companies are taking to telephone agents not knowing user's passwords is to ask for only three letters of them - the agent on the phone needs to type these in to have them verified - and this is not possible if the password is stored after processing with a salted hash.
The reason this is done is that it reduces reply attacks which is a significant concern for over-the-phone authentication. Using the three-characters-from-your-password method someone listening in to your call won't be able to call back and authenticate as you unless they have listened in to enough calls to piece together the whole password.
The usual method is to store the passwords in a strong but symmetric encoding which is no more secure than plain text if an attacker can get both the stored passwords and the key(s). the risk can be mitigated (though not completely removed) by making sure the keys are never stored anywhere near where the passwords are stored, but at some point in the process the key and the encoded password must meet for at least a brief moment.
Essentially this becomes a problem of weighing one risk against another: is the potential loss of security if the account data store is compromised justifiable when considered against the likelihood of successful replay attacks if you must hand over the whole password each time?
One suggestion I've seen is to store (salted and hashed) each combination of three characters without any external indication of which combination each hash represents (so for abcdefghi you would store encodings of 01a02b03c, 01a02b04d, and so on, meaning 720 stored hashes for that ten character password). That way you can check any combination by checking that the resulting hash value exists in the set. This is probably not a good solution though: if an attacker gets hold of the hashes then if they also know the salt they only need 46,656 attempts to derive the content of each hash (assuming a mix of numbers and single case letters is required) so 33.6 million checks would guarantee revealing a 10 character password instead of 3.6 thousand million million - reducing the processing requited by a factor of 100 million. I say "probably not a good solution" as I've done no analysis of this complexity compared to the relative non-safety of passwords stored in a reversible encoding - though I assume the fact I've not seen any such analysis from a trusted source either indicates that it isn't a solution relevant experts feel should be taken seriously.
14 comments
[ 4.7 ms ] story [ 49.1 ms ] threadI'm thinking of emailing them directly and asking the tech team.
And if they're not securely encrypted then I too will be taking my services elsewhere. My calls, bank details etc are logged. I don't want potential hackers knowing my parents number so they can target them and everybody else too.
If, instead, they were using a computationally expensive one-way function, a "password hash function", then an attacker would be able to get the digests it has produced, and maybe intercept a few live passwords as users log in, but they would not be able to trivially dump all the clear-text passwords wholesale. (Given the right password hashing setup, it is far too expensive to do so.)
It makes a lot of sense to use one-way functions for passwords: you only need to verify that a password is the same as the original (i.e. producing the same output when passed to the hash function); you don't need to know/remember what it is. There's no good reason for using encryption or storing them in plain text--"easier customer support" certainly isn't one.
More information: http://throwingfire.com/storing-passwords-securely/
But it doesn't have to be in memory, or otherwise stored, anywhere near the bulk account data. If the encrypted password is transferred up the application layers to another physical resource that knows the key, and the passwords (encoded and not) or securely wiped from memory immediately after the comparison then this offers some useful protection over plain storage. An attacker would need to compromise both resources (the data store and the key holder) in order to get hold of credentials. For this to be meaningful the security of those resources and the communication between them must be very carefully designed and implemented, but it is wrong to say symmetric encryption is necessarily no better than credentials stored in plain form.
> There's no good reason for using [symmetric] encryption
As per my other post (https://news.ycombinator.com/item?id=6120089) the reason this is done is to permit partial password checking which is used to reduce the chance of successful reply attacks. Unless there is a way of achieving both aims the decrease in risk (and to a certain extent perceived risk) through stopping the replay attacks needs to be carefully considered along with the decrease in risk through using storage methods that make this replay protection impossible.
Of course security keypads as used by some banks (my mortgage provider uses such a system) is a better solution, if well designed and implemented without cutting corners, but there are cost and convenience implications there which may put off the companies (cost) or their customers (the inconvenience of having a small device to not lose).
If the system can automatically verify a password, i.e. decrypt it, then an attacker can leverage that. You could design a system very carefully that might be invulnerable to memory injection attacks, might not be on boxes that have root escalation vulnerabilities, and which might be using a secure hardware security module--but why? You don't need to. Just use a one-way function.
> As per my other post (https://news.ycombinator.com/item?id=6120089) the reason this is done is to permit partial password checking which is used to reduce the chance of successful reply attacks.
Just add a PIN or something else that doesn't give you full access to the account. No reason whatsoever to store passwords people use on many other sites in what is, on 99.9999% of systems, equivalent to plain text.
Surely that can't be true? DPA shouldn't give them the ability to read our passwords, only the ability to save DOB, payment type (direct-debit etc) so you can validate that. But not passwords.
The reason this is done is that it reduces reply attacks which is a significant concern for over-the-phone authentication. Using the three-characters-from-your-password method someone listening in to your call won't be able to call back and authenticate as you unless they have listened in to enough calls to piece together the whole password.
The usual method is to store the passwords in a strong but symmetric encoding which is no more secure than plain text if an attacker can get both the stored passwords and the key(s). the risk can be mitigated (though not completely removed) by making sure the keys are never stored anywhere near where the passwords are stored, but at some point in the process the key and the encoded password must meet for at least a brief moment.
Essentially this becomes a problem of weighing one risk against another: is the potential loss of security if the account data store is compromised justifiable when considered against the likelihood of successful replay attacks if you must hand over the whole password each time?
One suggestion I've seen is to store (salted and hashed) each combination of three characters without any external indication of which combination each hash represents (so for abcdefghi you would store encodings of 01a02b03c, 01a02b04d, and so on, meaning 720 stored hashes for that ten character password). That way you can check any combination by checking that the resulting hash value exists in the set. This is probably not a good solution though: if an attacker gets hold of the hashes then if they also know the salt they only need 46,656 attempts to derive the content of each hash (assuming a mix of numbers and single case letters is required) so 33.6 million checks would guarantee revealing a 10 character password instead of 3.6 thousand million million - reducing the processing requited by a factor of 100 million. I say "probably not a good solution" as I've done no analysis of this complexity compared to the relative non-safety of passwords stored in a reversible encoding - though I assume the fact I've not seen any such analysis from a trusted source either indicates that it isn't a solution relevant experts feel should be taken seriously.