2

My bank provides online banking facility like most of the banks these days. On the web they have Partial Password Authentication. Although I don't really believe in PPA providing extra security but that could be wrong.

My Alarm bells started ringing when today I downloaded their mobile banking application for my smartphone. That app asks for my complete password.

Assuming the password is encrypted or hashed how does it allow both PPA and full password authentication?

Are my fears correct that they have possibly stored my password in plain text? In that case I will raise a complaint with their IT department and disable my account for now because everyone here knows much more than me how insecure would that be.

Edit:

Could they be storing each character of my password encrypted individually? That would then allow PPA and complete password authentication by comparing the available characters with their own encrypted versions. Is that a safe way of storing passwords for PPA?

Hanky Panky
  • 231
  • 1
  • 9
  • "Assuming the password is encrypted or hashed how does it allow both PPA and full password authentication?" ... by encrypting it or [storing hashes of the partial passwords and a hash of the full password]. –  Nov 05 '14 at 11:10
  • 1
    Ricky that may not be true. Every time you go for login you have to fill different characters for PPA. They wont be saving all the possible combinations of blank and non blank characters of the password in those hashes. – Hanky Panky Nov 05 '14 at 12:18
  • Why did your alarm bells only ring when you were asked to enter the full password? Its much easier to store the hash of the full password and then compare it with the hash of the user input. With PPA, if the different password combinations are stored encrypted and not hashed, then as per what I have learned throughout my work life, it would degrade the security, rather than improve it. – user1720897 Nov 06 '14 at 08:59
  • Because for the same password they are allowing full password authentication on one medium and PPA on another medium. Password can have a length of 15 so do you really believe they are storing that huge number of possible combinations in encrypted form? – Hanky Panky Nov 06 '14 at 09:06
  • @Hanky웃Panky Are you saying you thought they were only storing part of your password and not the whole? – user1720897 Nov 06 '14 at 17:06

3 Answers3

3

In order to support "partial passwords", the bank must necessarily store either the plaintext password, or at least some values that would allow fast reconstruction of the complete password. It is easily seen in the following way: when the bank asks for, say, the 3rd, 4th and 8th letters of the password, then there are less than one million possibilities (assuming that the "letters" are printable characters). Yet the bank can somehow decide whether the three provided letters are the right ones or not. Therefore, whatever the bank stores is sufficient to run a brute force attack on the 3rd, 4th and 8th letters, and that attack will succeed in less than a million tries.

The bank may add layers of encryption and hashing and whatsnot, this won't change that raw fact. Whenever there is support for "partial passwords", then there is very sensitive storage on the server side. In that sense, support for partial passwords decreases security, instead of increasing it. (It can be argued that partial passwords increase security on the client side: shoulder surfers gain only a partial view of the password. Yet you must be aware that this is a trade-off: more client-side security for less server-side security.)

To support full-password authentication, the bank must store something which is sufficient to verify a full password. The same reasoning as above applies, but for a brute force attack on the complete password, not on a partial password. If a bank supports both "partial passwords" and "full password" authentications, then it probably stores one of the following:

  • The full password in a "recoverable" format (plaintext, or encrypted with a key that the server knows -- that encryption being protection mostly against casual attackers on the bank side, e.g. underpaid interns).

  • A hash of the full password and hashes for all password subsets that the bank may ask to the connecting user.

The second possibility requires a lot more storage and implementation complexity on the bank side, so I deem it improbable. Developers of bank applications are no less lazy than their fellow humans.

Take note that your password is not your most sensitive asset entrusted to the bank. The bank holds your money. And the money is what the attackers are after. If an attacker completely hijacks the authentication server, he won't limit himself to grabbing encrypted or hashed passwords; he will immediately fake some successful authentication and trigger transfers. Who needs a key for a door when he is already inside ?

Discussions about encrypted or hashed passwords are relevant for partial breaches, e.g. when the attacker finds a backup tape for a database, or obtains a read-only view through some SQL injection attack. In that sort of scenario, what can be done by an attacker depends a lot on the subtle details of how things are implemented in the server, so it is hard to talk in all generality.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
1

They are probably storing the password encrypted (i.e. not hashed); encryption is reversible so there is no reason why they cannot use code which takes the user input characters, decrypts the stored password and checks the input matches the characters in the password.

If done correctly the program used to do this would only temporarily store the plaintext in memory and explicitly delete that memory after use (so that in the event of a crash the password is not written to a human readable file).

Though it is of course possible (unlikely?) that they are using plain text passwords.

As an aside...one way around the weakness of not having the password hashed (resulting from PPA functionality) is to have two levels of password, while this does not provide any additional assurance per se, it does mean that one password can be stored hashed (and always used in full) while the other is encrypted (and used for PPA).

The benefit of PPA is that it can help to defeat keylogging threats, even if an attacker has access to screenshots as well, they will need to observe and capture key strokes from multiple login events before they will have enough information to launch a successful attack.

R15
  • 2,943
  • 1
  • 12
  • 21
  • While possible that this is what they're doing, this answer completely glosses over the fact that such a non-hashed, encrypted password storage is only negligibly better than plaintext. Either way, this is a company you shouldn't be trusting with your birthday and your favorite color, let alone with your banking details. – Matthew Najmon Sep 18 '15 at 20:41
-1

Quoting wikipedia:

It is good practice to not store passwords in cleartext. Instead when checking a whole password it is common to store the result of passing the password to a cryptographic hash function. As the user doesn't supply the whole password it cannot be verified against a stored digest of the whole password. Some have suggested storing the digest of each combination of letters that could be requested but they note that this results in generating and storing a large amount of digests. A better solution in terms of storage space and security is using a secret sharing scheme.

Anonymous Coward
  • 227
  • 1
  • 4