Authentication controls - PIN vs Usrnm/Password

[Deyan]

Hey ISC2 folks,

Interesting debate I was involved in. Long story short:

A smartphone app uses authentication mechanism utilizing username-password combination. There are some controls that require the generation of strong password, minimum length, expiration, non repeating etc. After the user has registered and created their password though, the system gives an option to the user to generate a 4 digit PIN and use it when logging in instead of the user name/password combination. 

I guess I am asking - do you think that makes sense? Why would a strong password be required when after it - a user can simply use a 4 digit PIN (4 digit PIN = low security /around 10k combinations/)?

Additionally - are you aware of such practice is possible for mobile apps for regulated industries like banks/health?

[Badfilemagic]

The PIN is probably being used as a 2nd factor after the username and password credentials are received out from either the trustzone or secure element on the mobile device by the app and transmitted.

Consider:
- user registers account, picks strong password
- password is stored in vault on phone
- phone and user are compromised (user killed, for instance)
- attacker in previous step uses finger of phone owner to unlock device
- attacker uses finger again to retrieve credentials for banking app from SEP and transmit to server side from banking app
- attacker is now prompted for a PIN as well, foiling his evil plot despite having leveraged one of the gaping holes in remote use of biometrics to compromise the credentials stored cryptographically inside a secure hardware element on the phone.

Of course, they could also be doing something stupid or lazy with it, but i think forcing a manual pin entry into a field that can’t be populated with stored creds is a good thing, generally

[Del]

I've seen this with mobile banking apps ... where password and PIN are both required just to log in.

I think it's a great way to improve authentication, and reduce the risk of shoulder surfing, or guessing & re-using passwords.

The mobile banking apps I'm thinking of step it up a little by asking for randomly selected digits from the PIN (enter the 1st, 3rd and 5th digit at one logon, followed by 1st, 2nd and 4th the next time)

For signing transactions, a static PIN may not be suitable ... when moving money outside accounts for example; if that's the requirement, you're into One Time Codes or other transaction signing, non-repudiation techniques.

Simply put, a Password + PIN is "better" authentication than a password alone.

[Deyan]

Thanks folks but NO - the PIN is used INSTEAD of a user name/password combination - after initially the user register and put the strong password - he than has the option to not use it at all - but generate a 4 digit pin and log in with it from this point on as more convenient. This is what I believe - nonsense, however I was told that it is a practice in regulated industries like financial or health ones - which I strongly challenge - I've read PCI 3.0 and have not seen something like this. Your thoughts ?

[Del]

So the PIN is used INSTEAD of a User ID and Password? That seems odd.

Not a practice I've seen in the Finance industry in the last 17 years.

PCI 3.2 mandates 2FA ... see the PCI Council site here (https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss) and look for the PCI-DSS Summary of Changes, and then look at PCI Requirements 8.2, 8.3, 8.31, and 8.32.

I also note, with interest, that the authentication requirements in PCI-DSS 3.2 are listed in that document as "evolving requirements". I can't imagine that means PIN only anytime soon

[CISOScott]

I have seen it before. To log on to the network computer the user has to have a complex password, 14 characters long with complexity, etc.,  but logging on from the mobile phone only required a simple password of 6 characters. I fought against it as an ISSO but realized I was fighting a losing battle and left the company after a short period of time due to family medical issues, so I never got the chance to fix it.

Some people do not consider the phones to require as much security as a laptop or desktop. I have not figured it out yet where the lack of understanding is. Perhaps they think that if the mobile device is lost that the user will report it promptly and then the device can be disabled.

[denbesten]

This is a simple example of risk-benefit analysis.

Since we don't know the app in question, we need to make a few presumptions:

1. The app probably requires the username/password when logging in and that the PIN is used to unlock the app on a device after the user previously logged in.
2. The pin likely would not be accepted if the user explicitly logged out.
3. I'm guessing that using only YOUR PIN on MY device, I could not get into YOUR account.
4. The data being protected likely is not a state secret or is data that belongs to the user.
5. There is value in convenient access to the data.

I immediately see a few mitigating factors:

1. The attack surface for the PIN is fairly small.  An attacker needs physical access to your device and the app must be logged in to your account.  A company protecting credentials inside their own dedicated app is not the same thing as trying to protect credentials within a web browser with unknown plugins.
2. We don't know how the app behaves after too many incorrect PIN attempts. The app may disable the PIN after a dozen failures, and fall back to the password.  If the limit is reasonably small, brute force is unlikely to succeed.
3. It is entirely possible that the app only gave you the option to set a PIN after validating that your device's security was up-to-snuff.  The Outlook app, for example does this.
4. The PIN is optional; the user gets to decide if the convenience is worth the risk.  In our language, the data owner is charged with perform the risk analysis. 

My credit card app allows this and I think it is a good thing.  After having securely logged in once, I can subsequently fingerprint in. It only allows me to see my current balance, recent transactions (permitted or denied) and to freeze/unfreeze my card.  I enabled fingerprint because there is little damage an intruder can do, whereas it makes it easier for me to detect, report and prevent fraud.

My Amazon account, on the other hand, has 2-factor and a 30-character random password because I strongly want to defend against an intruder using my stored credit card.

[Deyan]

Thanks all for your inputs. Yes, I believe that maybe it is not yet realized that the smartphones are identical threat vectors to the normal computers/laptops. Also I think that with the smartphones the convenience vs the security component is in play but still - the described scenario poses a huge risk related to the authentication.

[JoePete]

---

@Deyan wrote:

I guess I am asking - do you think that makes sense? Why would a strong password be required when after it - a user can simply use a 4 digit PIN (4 digit PIN = low security /around 10k combinations/)?

Additionally - are you aware of such practice is possible for mobile apps for regulated industries like banks/health?

---

We've seen something like this with fingerprint authentication. You enroll a fingerprint (i.e. something you have), but then can use an alternate (i.e. something you know) authentication with a PIN or username/password combo. It's a bit odd, however, to have a PIN replace a username/password.

I wouldn't get too hung up on the possible combinations issue. A larger issue is whether there is some form of account lockout, and then you also need some sense of how the authentication is used. For example, let's say on the backend of this app is an Internet-accessible application with a database that stores that PIN (even hashed and salted) and all the app does is pass some hashed value to the application. Not so good - on several levels: A compromise of either the database or the application (e.g. someone is able to feed it an unlimited number of hashes) and it's game over. However, let's say that PIN is used to encrypt some very long hash stored in the app on the phone, and then that hash is what the app uses to authenticate to the backend, that's probably a lot more secure than, say, an app that transmits a username and password (maybe even in clear text) to backend application. There are a lot of variables. My point is don't conclude the PIN iceberg is smaller than the username/password one because it only has four feet sticking out of the water.

To the second half of your question, though, I find most regulation does exactly that - measure security based only on some superficial metric (e.g. bit length) rather than something more comprehensive (but granted, harder to measure).

[Shannon]

Sorry I saw this so late --- but better late than never. Secure authentication requires provision of credentials consisting of / using the following: -

1. Something you know (e.g. Password, PIN)
2. Something you are (e.g. Bio-metrics)
3. Something you have (e.g. Mobile device, Token generator)

Single-factor authentication uses only 1 of these, and multi-factor authentication more than just 1 of them.

Allowing the use of a PIN may appear to be lax security --- but if you look closely, it might be multi-factor authentication, assuming the system was designed properly.

A well-designed system will accept authentication with just a PIN only after the user has initially provided adequate authentication with a password & / or bio-metrics. The user initially uses a password, and for all subsequent logins, the PIN by itself is accepted.

Initial authentication with a password makes the device trusted --- so any subsequent authentication is effectively a combination of something you know (PIN) and something you have (mobile device).

It can be perceived as multi-factor authentication portrayed as single-factor authentication. 

So if we're talking about a properly designed system AND a user who knows what he / she is doing, it would make sense.

(I don't know whether it's allowed / regulated in applications used by banking or health sector organizations)