5

CertiVox have designed a system with the aim of "getting rid of passwords".

Essentially the system authenticates users with two factors of authentication: A 4 digit PIN and a token stored within the browser's HTML5 storage. There is also the option of authenticating with a mobile phone by entering a one time passcode which is displayed on your computer's screen on the website you are trying to authenticate with. I believe this also requires the HTML5 storage token to be present. I'm assuming some sort of cross-domain call will enable the JavaScript to get what it needs to validate the token stored in the origin of the authentication server in both cases.

There is no password database as the system uses cryptography and zero knowledge proof in order to authenticate you with the service you are logging into. The keys are split between their master server and your own hosted server (in the case of M-PIN SSO).

CertiVox are the same company that ran PrivateSky, which was taken down at the end of 2013. There is a question relating to PrivateSky on here (How can PrivateSky not see your data?) and it seems to have similarities in the way it works to M-PIN. See Brian from CertiVox's answer here.

On first impression it reminds me of what SQRL tries to achieve. Related posts to SQRL are here:

A page covering M-PIN in depth is here.

My thoughts are:

  • The MITM scenario is not possible like it is with SQRL because the MITM will not have the token in their browser.
  • As the token is stored in the browser, this becomes the prime target for any attacker.
  • The PIN entry in the browser is susceptible to shoulder surfing, although useless without the browser token.
  • A phishing attack could retrieve the PIN, again useless without the browser token.

Are my above assumptions correct? Are there any other weaknesses or advantages over using something like LastPass Enterprise (say using 100% generated passwords with 128 bit entropy and Yubikey 2FA for LastPass login)?

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178

1 Answers1

3

this is Brian from CertiVox.

I'll answer your questions line by line:

The MITM scenario is not possible like it is with SQRL because the MITM will not have the token in their browser.

You are correct, the MITM scenario is not possible as M-Pin is a zero knowledge proof challenge response protocol. A MITM attacker would only see big numbers flying by. The worst an attacker could do is to modify the challenge or the response, in which case the authentication would fail.

As the token is stored in the browser, this becomes the prime target for any attacker.

That's true. However, recommend to our customers to use CONTENT-SECURITY-POLICY HTTP Header since the M-Pin PinPad works without a problem with this setting turned on. This protects against almost all the possible XSS attacks known. Offline attacks to the LocalStorage are possible only if the browser (computer) is infected with a malware. There is no existing single-device authentication solution that can solve that problem, as far as I know. Also, we have an M-Pin Mobile app (HTML5, iOS and Android) that keeps your token in your mobile instead of your browser, as you mentioned. This enables the "Global Authenticator" mode so you can use it to remote login to desktop sessions. Adding the TEE support, the token is not just in your mobile but in secured hardware inside your mobile.

However, I think you might be missing the point of M-Pin; As you say, the target of the attacker (the individual) is now the only way of compromising their authentication credentials.

The big problem in the news cycle right now is attackers are stealing everyone's passwords out of the credential's file or password database inside large enterprise systems - out of the server, not at the client.

THAT'S THE REAL PROBLEM M-PIN SOLVES.

An M-Pin Server stores no authentication credentials, ever. It doesn't matter if you salt and hash them 30 rounds. If you are in a regulated industry, you are obliged to tell the world you have been hacked and advise users to change their passwords. This can lead to a loss of confidence among customers. See Yahoo, eBay, Evernote, LinkedIn, etc. etc..

So if you are an enterprise or are running a mobile app or web app, implementing M-Pin as your authentication platform eliminates that threat vector and that risk of reputation damage.

The PIN entry in the browser is susceptible to shoulder surfing, although useless without the browser token.

Exactly. Compared to password only, it's obviously eliminates that risk.

So you are right, shoulder surfing is useless without the token as a means of attack.

Also, in the new 3.4 version (that is in testing stage), we have implemented keyboard input support that will help you to type the PIN number without worrying that someone will see it on your monitor.

A phishing attack could retrieve the PIN, again useless without the browser token.

That's actually one of M-Pin's powerful strengths. Any spoof website can prompt a user to enter some private information. In M-Pin's case that information can only be the PIN. That PIN is completely useless without the token and without the M-Pin ID (which is different for each registered browser). Also, the spoof site cannot know the user identity - it is shown in the PinPad when asking for PIN number.

In comparison to LastPass, they are trying to help manage passwords. CertiVox M-Pin is meant to eliminate them entirely. Our 'M-Pin Core' value proposition isn't aimed at the individual (like LastPass), ours is aimed at developers and / or CISOs / security professionals who are implementing large, Internet scale applications and want to eliminate the risks that come from using password based authentication.

Our 'M-Pin SSO' server is aimed at Enterprises who want to federate M-Pin Strong Authentication to SAML / RADIUS enabled applications internally or externally.

Hope that helps.

Cheers, Brian

Brian Spector
  • 346
  • 1
  • 2
  • 6