User Tools

Site Tools


Using S-CRIB Scrambler

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.

 Two Scramblers with Raspberry Pis

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:
“passw0rd”; or

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.

Proof of concept is using Raspberry Pi with Raspbian (an optimised Debian) and setup instructions are at our GitHub repository.

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.

Why Hardware Scrambling

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 ( 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.

How Scrambling Works

Let's assume we will use it with WordPress. The login process will then be as follows:

  1. User enters her password (“123456”).
  2. Password gets to the verification code - either in the core or to a plugin if there is any.
  3. WordPress will send the password to a Scrambler and receives back an encrypted value (6C93BBFA75C81B4A9F3AEA443E7FFB7E8599B391).
  4. It reads an encrypted value from the database and compares it with 6C93BBFA75C81B4A9F3AEA443E7FFB7E8599B391.
  5. If the values match, user logs in. If not, user has to try again.

How Secure Is It

S-CRIB Scrambler uses a set of keys:

  1. 32 character key to scrambler passwords = compute SHA1-HMAC. This key is only in the Scrambler and optionally in your strong box if you ever need it for recovery or for creating a cluster of Scramblers.
  2. another 32 character key to encrypt communication between itself and the server (data for the ENSCRAMBLE command). This key is shared with the server. It means there is higher risk of it being compromised and that's why it is separate from the first key.
  3. API key - that is not in the dongle but the server will use it when calling Scrambler Web Service. Our test installation at uses API key “george” but in real life it would be a 20-32 characters long random string.
  4. a short 10 character key that identifies Scrambler's cluster and is linked to the API key. It basically tells the web service with Scrambler to use if it hosts more than one.

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:

  1. Only allow access to Scramblers locally - through localhost network interface or from your LAN (adjusting your firewalls).
  2. Enable HTTPS between your server and Scrambler's host (Raspberry Pi in our demonstration setup).

How Do We Protect Against Eavesdropping On The "Line"

There are basically 4 separate hardware/computer elements in the system:

  1. User's computer
  2. Server hosting WordPress
  3. Host of S-CRIB Scrambler(s)
  4. S-CRIB Scrambler(s)

We aim to protect communication between 2, 3, and 4.

  • User computer ↔ Wordpress - out of scope for Scrambler.
  • Wordpress ↔ TCP/IP stack - encryption of ENSCRAMBLE
  • TCP/IP stack ↔ Scrambler host - HTTPS/SSL if configured (optional if one wants to sort out certificates)
  • Scrambler host ↔ S-CRIB Scrambler - encryption of ENSCRAMBLE

The Security Stands And Falls With Encryption Key

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).

Why Not Use BCrypt

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?

Can Attackers Acquire Password Before Encryption?

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.

Scrambler Sounds Like HSM

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.

Setting Up

Linux setup - tested in Raspbian (Ubuntu for Raspberry Pi) is being updated at GitHub.

Being updated …

Further Documentation

how_to_use_scramble_scrib.txt · Last modified: 13/03/2014 10:17 by Dan Cvrcek