Partial Password Verification

Question

I want to be able to ask for a username, retrieve the users password and then randomly pick 3 characters from the password and ask for verification on those characters. Basically like a bank does.

I can't find any examples of this, I have an authentication procedure already set up -

 Public Function IsAuthenticated(ByVal domain As String, ByVal username As String, ByVal pwd As String) As Boolean
    Dim UserAuthenticated As Boolean = False

    If SafeString(username) And SafeString(pwd) Then
        'Is user authenticated in active directory


            Dim domainAndUsername As String = domain & "\" & username
            Dim entry As DirectoryEntry = New DirectoryEntry("", domainAndUsername, pwd)
            Dim search As DirectorySearcher = New DirectorySearcher(entry)
            search.Filter = "(SAMAccountName=" & username & ")"

            Dim result As SearchResult = search.FindOne()
            Dim obj As Object = entry.NativeObject
            UserAuthenticated = True

Does anybody have any examples

Answer 1

Your quesiton may be answered here: Password systems which ask for individual letters - what do they store?

The short of it is that partial password verification opens up your database to more vulnerabilities, as you will either have to use a decryptable password (very bad) or store more information regarding your password which makes it easier to brute-force if your database is compromised (bad).

"k-out-of-n threshold secret sharing" looks to be the safest approach.

Answer 2

You appear to be authenticating against an Active Directory backend. AD doesn't provide any possibility to validate partial passwords.

(Aside: you should be LDAP-escaping the username before including it in a query, to avoid query injection attacks.)

To do a partial-password login you need a password store with recoverable contents. The usual practice is to store the passwords in a database with symmetric encryption. This is better than plaintext, in that an attacker can't get the passwords through just compromising the database/server, but they can still get them if they can compromise the web application/server enough to read the encryption key. (Hardware decryption can help here using an HSM, but still no use if the attacker has enough access to run all the passwords through the app.)

Adding application-level password encryption adds complexity, especially setting up infrastructure and processes to securely manage the lifecycle of the encryption keys. And even if you do all that, and consider rate-limiting and auditing to try to detect and prevent a password database, it's still a weaker story than the industry standard of storing passwords as strong hashes (like bcrypt or PBKDF2).

(Aside: although in principle you could store partial passwords as a collection of hashes of each n-letter combination, this makes the amount of entropy in a single hash very low, such that even with strong hashes it is easy to brute-force one combination, from which one can then incrementally break adjacent combinations.)

Partial passwords also have other drawbacks: as they are lower entropy than a full password there is a higher chance of successful random guessing (typically you enforce more severe lockout restrictions and rate-limiting to compensate, at some usability and operational cost); they put restrictions on password length that make users more likely to choose weak passwords and less likely to choose memorable ones; and they make it difficult to enforce password strength measurement (eg: the password pass8R$kO is reasonably strong by itself, but not so much when you are prompted for the first three letters). You will also need to keep track of which letters you currently want for each user, otherwise an attacker who has obtained a few letters of the password can simply reload until they are prompted for the characters they know. (It's amazing how many partial-password logins get this wrong, making the whole exercise pointless.)

All in all, partial passwords have at least as many downsides as benefits, and are not a simple win you can always deploy to ‘improve’ security. For some threat models, and with a strong regime of auditing and app/infra security control, one could argue they have some use. But for the general case they are typically regarded as not worth it.

This doesn't stop the use of key loggers though

Nothing stops the use of keyloggers, you can't possibly win against an attacker who has control of the user's interaction. Anything that makes the login page unusual (such as partial password, virtual keyboard, or others) will stop only the laziest general-purpose keyloggers. More sophisticated trojans will still be capturing the input through a variety of methods, or even (commonly amongst banking trojans) silently replacing your partial-password input control with a plain password box!

Partial password is usually designated more as a counter to low-grade phishing attacks (fake login form links) than client-side trojans, although it is unclear how effective it is for this case either.

risk of people visiting clients and using unknown computers and accidently clicking 'Remember Password'

Ah, well that's a different matter. Unwanted password managers can be worked around, although browsers are beginning to ignore autocomplete here, necessitating more annoying JS fixes, sigh.