So, what is this Identity Provider stuff, and why is it hackproof?
Two-Factor Authentication relies on two things (strangely enough...)
- Something you know - like your password or PIN code
- Something you have - like an ATM card or device
Secure authentication demands that it should be impossible for an attacker to deduce both factors by:
- Physically observing your login
This can be via a spy camera or, simply, the guy behind you at the ATM queue
- Reading your keystrokes as you login
Malware on your device can grab the keyboard codes, and send them back to the attacker. Other malware can read the hardware frame buffer, where the image of the web page is stored, and strip the user ID, credit card number and PIN code or password from the page. In the case of Target, the malware did this on the POS terminal itself.
- Intercepting the network traffic between you and your login target
Once the data has been submitted, it can be intercepted by a network snooper, and saved for use in a 'replay attack'. It doesn't matter if you use biometrics, since the biometric data is digitised, and can be easily read and stored.
- Stealing or accessing the credential store on your login target
Someone, somewhere knows where your credentials are stored. The system administrator or DBA can access the database, malicious insiders can steal it. Even if the database is encrypted, the sys admin or DBA will know where the encryption keys are stored. Others can find out.
Let's discuss the Second Factor first.
Every device used to access the internet does so with a unique combination of these parameters:
- Device type - laptop, smartphone, desktop, mainframe etc
- Device CPU - each CPU is different
- CPU clock rate - although the nominal speed is fixed, it varies by a fraction
- Graphics adapter - no two are identical, and the clock rates differ
- Operating System and version - Solaris, Unix, Linux, iOS, Android etc
- Browser type and version - Safari, Chrome, Firefox, Opera etc
Together, all these parameters create a unique signature for a device, which we do without the installation of cookies or any other kind of software on the user's device.
The user can register as many devices as he needs to any application to which he is subscribed, and the system will check the device used for incoming login attempts. If a device is unrecognised, the login will fail, even if the user enters the correct credentials.
So, what about the First Factor?
When entering his password, the user neither enters, nor transmits any useful data. Just metadata, which changes with each login. The combination of the device signature and the password metadata is unique, and cannot be used in a replay attack.
To an attacker observing the metadata, it is just random garbage, which is never the same, from one authentication to the next.
In operation, each user has a password or a passphrase, such as "IFeelGood", which is known only to him. The reason it is known only to him, is that, when the user is first registered, the password is null, and he is presented with an entry form. He enters his chosen password, and its hash is sent to the authentication server. Thus, not even the sys admin knows the actual password.
If the user wants his password reset, the sys admin can only clear it, and cannot set it.
If, when logging in for the first time, the user is presented with a login screen, he knows that the account has been tampered with.
Here's the challenge screen:
As you can see, it comprises two panels, each containing a random mix of letters of the alphabet.
The user then spells out his password, by clicking on whichever panel contains the appropriate letter. The progress bar confirms the entry of each character.
This results in an extremely fast and friction-free login. No calculations to make, no patterns to match and no keyboard to take up valuable screen real-estate on your phone.
For example, entering the password 'fred' would require clicking on
top top bottom bottom
So, what about spy cameras and the guy looking over your shoulder? Can't they guess your password by watching where you click?
- First, the content of the panels is random, and changes with each attempted login. Any information gained from an observation would be useless for a subsequent login.
- Second, the two panels are actually monolithic bitmaps, and you don't click on individual letters. Wherever you click on them, the result is the same, so any malware reading the frame buffer, or logging keystrokes will be sadly disappointed.
- Also, when the system is set up, you can specify a prefix and/or suffix of random characters to your password, so even its length becomes unknown.
If Target had employed this system, the frame-buffer reading malware would have logged nothing.
Just to make sure that the information is useless, we don't send it anywhere. We send a SHA256 hash, which is irreversible, of the clicks,
Put this together with the device signature, and you have a system which provides no information useful to an attacker.
What about Single Sign-On?
DSS Enterprise follows the SAML protocol, but without the unnecessarily complex message format, which makes interfacing to SAML servers such a nightmare.
You can initiate single sign-on by simply using the same password for all the applications of which you wish to make a sign-on group. From the interface perspective that's it. DSS Enterprise keeps track of all the authenticated sessions.
On the other hand, to help your applications keep track of what you are authenticated to access, DSS Enterprise issues a JSON Web Token (JWT), when you have successfully logged in.
You know the drill. Your applications pass this token among themselves to confirm that you are still you. However, if you don't want the added complexity of maintaining the tokens, and your network has the bandwidth to support many users constantly accessing the authentication server, our session handling algorithm can easily keep track of who is authenticated to access which application.
How do we protect data at rest?
Sensitive data in your database is encrypted using strong encryption, via AES256.
In most systems, the system administrator and the DBA know both the location and the value of any encryption keys used to protect the data in the database ("Data At Rest").
For obvious reasons, this is not A Good Situation. People leave companies, people become disloyal, and people are careless.
The solution to this, is to make sure that the encryption keys are not physically stored on any machine, and that nobody knows what their value is.
When you first install DSS Enterprise, the executables won't run, until the machine's root user sets the encryption keys.
The values of the keys are not communicated to him, and even we can't access them.
When, as demanded by Best Practice, the keys are set to new values every few months, the database data is re-encrypted using the new keys which, as before, are not known to anyone.
Need more information?
Get in touch
Back to Home Page