Many banks and other systems have some sort of a "select the Nth, Nth, and Nth characters of your password" system.

I don't believe they are going to be storing in plain text, nor would it make much sense to hash and salt each character of the password. Someone I asked mentioned they believe there are algorithms that can check or manipulate parts of encrypted data.

Do these algorithms exist and how do they work?


Most financial services companies that I've come across who make use of this kind of system are encrypting the password using a Hardware Security Module ("HSM").

In this kind of system the password is symetrically encrypted with a key held in the HSM, and then stored on disk. The application will then pass the encrypted password and the individual characters into the HSM which will decrypt the password, make the comparison with the supplied characters and return a true/false answer to the application.

The security of this kind of system relies on the intended properties of the HSM which should be resistent to tampering and which run a very limited number of functions to reduce attack surface.

Also in this kind of situation key management is obviously very important as compromise of the key would allow for easy access to all customer passwords. This tends to lead to split authority and key parts being stored in safes, as a backup for the HSM.

  • $\begingroup$ -1 Although informative, this answer doesn't really answer the OP's question about algorithms checking/manipulating parts of encrypted data. $\endgroup$ – Maybe_Factor Feb 13 '17 at 5:06
  • 1
    $\begingroup$ That's because what OP had heard, in my experience, is incorrect. Banks do not use algorithms that manipulate parts of encrypted data, they use HSMs $\endgroup$ – Rory McCune Feb 13 '17 at 9:17
  • $\begingroup$ So do you have an opinion on, or has much been written about, how secure this practice really is? Presumably if you can compromise any application or system that has access to the HSM you can trivially retrieve plain-text paswords, which is vastly less secure than hashing incoming password attempts and comparing them, where the plain-text password is never revealed. $\endgroup$ – Robin Winslow May 29 '19 at 14:29
  • $\begingroup$ If implemented correctly that should not be possible. The HSM takes the encrypted password and a answers the question (for example are these two characters in this password at these positions). It should never return the clear-text password. Also a well configured HSM will have rate limiting to prevent brute force guessing attacks. Of course, a poorly implemented HSM based system can be insecure, but then, so can a poorly implemented password hashing system. $\endgroup$ – Rory McCune May 29 '19 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.