S-CRIB Scrambler is our latest product (January 2014). It helps protect user passwords stored on servers by scrambling them with a secret key that is only present in a hardware device connected or used by servers.
You can actually purchase S-CRIB Scrambler and become an early adopter. We would love to test the concept and implementation in real systems.
Effectively, password files can be compromised or even published without leaking any information about user passwords. Passwords would still be as secure and attackers would not be able to say whether it is:
We want to make S-CRIB Scrambler as easy to use as possible. We therefore implement a web-service (implementations in Java and Python) that will allow very easy integration to most of online content management systems or any other application.
Ultimately, instead of calling a hash function to scramble passwords entered by users, the server calls a web service (hosted locally or remotely) to do it. This web service scrambles passwords with a “keyed cryptographic function”. The key is not possible to read from the hardware device once it is initialised (= after the first call of SCRAMBLE / ENSCRAMBLE command). This makes the system sufficiently secure for almost any commercial application.
Password hashes stored on servers are the easiest target for any attackers (not only hackers). If we can replace hashes with encrypted values we improve security. When we make the encryption key impossible to read we can't make it much more secure. The best place to hide the key is to put it to another hardware with simple API.
When we met with a friend of ours who is active in cryptographic APIs in June 2013, we talked about an idea of moving cryptography for authentication into separate hardware devices. Other researchers have been thinking along the same lines as well. The second train of thought comes from a project we kind of keep alive since March 2013 - to build a cryptographic module (HSM) suitable for the Cloud - project Nikka (http://smarthsm.com/). We have developed an initial design and a proof of concept but we didn't have suitable application.
We got to stage when we needed to develop a web service for the HSM idea - project Nikka - and we decided to design it so that we can use it for password “scrambling” as well as for our HSM concept.
Let's assume we will use it with WordPress. The login process will then be as follows:
S-CRIB Scrambler uses a set of keys:
The length of keys is enough to prevent any cracking attempts. 128 bit keys are currently secure for any application and our keys provide 199 bits. (Each additional bit doubles the cracking effort.)
Scrambler does not have any function to export the key once it's been initialised. It will only use it internally to scramble passwords.
The strength of the keys is paramount so if you don't trust the Scrambler's internal generator, you can import your own key during initialisation. It will be combined with a unique hardware key that is in Scrambler's internal FLASH memory.
You can improve communication security with two additional measures:
There are basically 4 separate hardware/computer elements in the system:
We aim to protect communication between 2, 3, and 4.
The key strength is the main issue as it is THE thing that provides security. That's why we limit the exposure of the password encryption key (one used for SHA1-HMAC). The scrambling key can be backed-up and exported but only before the first use of the Scrambler. Also users can generate their own set of keys and import them to Scramblers if they have better random generator.
We use a separate key to encrypt communication between Scramblers and server. This communication key must be on the server that is usually easier to hack. Unfortunately, there is little we can do about that.
Regarding SHA1 strength - it is still FIPS-approved cryptographic function that is widely used by pretty much everyone in industry. As we use it to protect passwords and only as part of the HMAC algorithm, the birthday paradox is not a problem and SHA1 still provides complexity close to 160 bits (existing attacks are only on collisions and if we grossly overestimate those and just double their results, we still get the strength of 122 bits - I refers to crypto analytical results from 2005/6 and abandoned implementation from 2010/11 - project HashClash).
BCrypt is a special cryptographic algorithm (a key derivation function) that is on purpose very slow. One can configure its speed to provide, e.g., 10 scrambled password values per second.
We don't like this blunt approach as it assumes known ratio between computational power of “business system” and attackers. We much more prefer creating complexity through the strength of cryptographic key as we can compare that against state-of-the-art attacker regardless of platforms used by internet servers as some of them are pretty slow.
Let's say you have a virtual machine running Windows2008R2 with 1GB of memory and shared processor for your online system. Would bcrypt that is configured for this platform really protect passwords with 20-30 bit entropy against offline attacks using massively scalable and cheap platforms like Amazon EC2 or BOINC?
Passwords sent to Scramblers are encrypted end-to-end so the attack surface is fairly small (inside dongles or inside the server's authentication code & login web page). Additionally, remote communication can be over HTTPS. HTTPS starts and ends at TCP/IP stack so the attack surface for eavesdropping is larger.
It is correct that if attackers can penetrate the server and listen and store passwords on-the-fly, our Scrambler will not help to protect against it. However, the complexity of such an attack is quite different and much higher than just stealing the database of stored user account data.
Absolutely, S-CRIB Scrambler is basically an HSM. What we are aiming at long-term is to build devices that behave like HSMs but are suitable for ordinary use - consumers, small companies, small online publishers, and so on. It means they provide a simple API with functionality that is useful, and are reasonably priced. The market of HSMs is in a sense similar to PKI technology in 90ies when there was a lot of investment into the technology and companies were building “infrastructures” but there were no useful applications.
People often overlook that smart cards provide actually better security than HSMs while they are 1000x cheaper and still with enough computational power for many applications. I am still amazed by what can be achieved with cheap and relatively slow platforms and products when used properly.
Linux setup - tested in Raspbian (Ubuntu for Raspberry Pi) is being updated at GitHub.
Being updated …