7 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

I agree with StrangeWill's answerStrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

6 Added a link to the referenced answer
source | link

I agree with StrangeWill (+1)StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill (+1); it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

5 added 46 characters in body
source | link

I agree with StrangeWill (+1); it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

The other alternativeIf they potentially could be doing is thataren't storing the password in a reversible format then they must have pre-stored hashes for you for each of the 56 different permutations (if youyour password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate standard hashes at billions of (standard - md5/sha1) hashes per second; this is very little security -brute- if anyone obtained their hashes; they'd be able to crack all of themforced in under a second. (They They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords. combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill (+1); it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

The other alternative they potentially could be doing is that they pre-stored hashes for you for the 56 different permutations (if you password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate standard hashes at billions of hashes per second; this is very little security -- if anyone obtained their hashes; they'd be able to crack all of them in under a second. (They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords.)

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

I agree with StrangeWill (+1); it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

4 GRRR: can't do 8 choose 3 properly.
source | link
3 added 876 characters in body
source | link
2 added 876 characters in body
source | link
1
source | link