4

There's a system that users can either login with their national id and their password OR their customer id and their password. The password is common in both cases for a certain customer (every user may have up to one account since they have one national id).

It is estimated that users can remember their national id better than their customer id, so the preferable way for login in this system is login with national id, and login with customer id appears as a secondary option, recently this system is going to be combined with another system where users are used to login with their customer id (of course they also know their national id, but it's just the way it was before and so they're used to it).

We want to engage the users we already have in the second system to use their national id to login, and yet keep the option of logging in with the customer id open (as it is now in the other system too), the problem is they've never used the national id to login (as it wasn't an option before in the second system), so maybe their preferable way of logging in is customer id till now, and they get confused when they see the field of logging in with customer id is replaced with the field of national id and although they know their national id, they don't see it as a way to login.

But once they know the fact that login with national id and customer id has the same result and their password doesn't need to change, it's estimated that they will prefer national id too. Also the new users to the combined system (no matter which services they want to get) will prefer national id and so customer id will always be a secondary option from now on.

What should be done here to inform the users of the second system that they have a better option to login now and engage them to use this second option?!

Also pay attention that distinguishing between the national id and customer id is almost impossible for the system as long as they may be too similar. So having a field with a placeholder like national id or customer id is impossible here.


Edit: As I see it repeated in answers, no there's no way to distinguish the customer id from national id, they are both the same length and the customer id is a random number assigned to a user, and it's even possible to type in the customer id for some specific users.

  • 1
    What country is this? It sounds similar to the Danish national digital login system, which also allows person-ID-number or self-chosen-username. In this case, not using the person-ID-number (in fact, disabling it as a login option) provides better security, as an attacker would then need to guess both field values. (Just sayin', and therefore not an answer.) – KlaymenDK Aug 2 '17 at 12:50
  • @KlaymenDK You are probably right. But as I said it's always easier for people to remember their national id than another long sequence of numbers. – Jack-in-the-box Aug 3 '17 at 12:22
4

I like the word 'impossible,' as nothing should be.

If you have a singular input for customer ID or national ID and you attempt to match the number and password with the first value or the one you'd prefer to check first.

The user is either authenticated or not.

If, not, attempt to validate them with the second credential.

They are either validated or not.

Seems simple to me.

UPDATED ANSWER

OK, you're pretty adamant nothing can be done on the back-end, I guess the option left is to try and guide the user as much as possible. Although you can' restrict the user from typing the customer ID into a national ID field and vice versa, we should try and inform them what is needed in the fields to successfully log-in.

Selecting different log-in

  • As I said they are way too similar and we don't know for sure but it may be possible that customer id of a person be similar to national id of another person (as the customer id follows no special pattern and is a random number and can be even typed in, so the admin can type in whatever customer id they want), and it may seem improbable if they have the same password, but yet it's possible, so there's a bit of a security problem with that. – Jack-in-the-box Aug 2 '17 at 9:01
  • 1
    Perhaps the creation of the IDs is the real issue, can anything be done to produce a more formalised creation process? Looking at your comments to the other 'answer' is would solve the problem at root. – DarrylGodden Aug 2 '17 at 9:31
  • 1
    @Jack-in-the-box I think you're overestimating the security impact. Yes, it makes it 'twice' as insecure, but it's just as big a security risk as someone mis-typing their account by one number. I'd be more worried about standard stuff like dictionary attacks, and I wonder how you're going to store the PW (can't hash with both numbers I think?). But hey I'm not a security pro so you can take this with a grain of salt. – PixelSnader Aug 2 '17 at 10:03
  • 1
    I was thinking of doing that, but with the tab style, I wondered whether the user may consider it 'detached' from the login process. Would need a little wireframing and some user research. – DarrylGodden Aug 2 '17 at 12:53
  • 1
    @KlaymenDK as it is stated here, it may confuse the users that what could happen if I leave one field not filled or the other way. The way UXform12 suggests is better actually. But thanks for your comment :) – Jack-in-the-box Aug 3 '17 at 12:17
3

This is a great time to begin an onboarding period for your customers. Allow them to continue logging in with their Customer ID, and after verifying their login, mention to them the new change with the effective date and display for them their National ID. If possible, you could even give them the option to use the National ID by default by letting them opt-in during the onboarding period and then setting a cookie that will take them to the National ID view when navigating to login. After the end of the onboarding period, everyone will use the National ID login view by default and you can present for them the option to use their Customer ID as an alternative if desired.

1

".. distinguishing between the national id and customer id is almost impossible for the system as long as they may be too similar."

Can you expand more on this? Does each of ID's have different length? Do they have specific algorithm through which they are generated and can you use it to verify them?

Because, if the two ID's differ in lets say length, then your software should be able to automatically distinguish them?

The only case is that user accidentally inputs wrong number, let's say National_ID instead of Customer_ID. In that case, if password is the same for both, just log them in. If it's not, state an error message saying:

"Are you trying to log in with Customer ID instead of National ID?"

That should get your users to think which one they are using, and which password are they putting in (if they are different).

For existing users, once they log in with Customer_ID show a message saying:

"Did you know you can now use National ID?"

Show a page or a button where they can confirm that they also want an option to log in by National ID. There they will have to input it, confirm it and from that point you can create another log in for them. True, this leads to other account log in being unused, but my guess is that should not be too much for database to handle.


TL;DR:

Eliminate placeholder or any type of distinguishes between login ID, and depending on user input recognize the required next step for them.

  • Of course I've considered that when I said it's impossible to distinguish them. They are similar in length and also customer id follows no specific pattern and is totally random, and it is even possible to type it in. So that's not a solution. – Jack-in-the-box Aug 2 '17 at 9:07
  • Are you saying it's possible for a valid CustomerId to be a valid NationalId? – jk47 Aug 2 '17 at 14:23
  • @jk47 Yes, pretty much! – Jack-in-the-box Aug 2 '17 at 17:04
  • 2
    @Jack-in-the-box then what happens if user A has a CustomerId == '123' and user B has a NationalId == '123'? If it really works like that then you have a pretty serious security flaw in your system. – jk47 Aug 3 '17 at 8:59
  • 1
    @Jack-in-the-box Seems like a third unique identifier would solve that problem. But that's just additional info for user to remember and input. And btw nothing stops me from trying my own credentials in different input field (Customer instead of National). But that is illogical and very unlikely that anyone would try. But still... (just having a thought out loud, sorry for not being more constructive here) – Blaze Aug 3 '17 at 12:06

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.