Virgin Media - Your plain text passwords are safe with us
twitter.com
twitter.com
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.
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.
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.