HACKING VENTURES

11 March 2014 by Einar Otto Stangvik

The S-CRIB Scrambler, and how long-term solutions aren't immediate

The S-CRIB Scrambler was, as far as I can tell, released in January 2014. On March 7th, a solution combining two of these devices, connected to a Raspberry PI, was described in a post made to the Light Blue Touchpaper.

In short, this is a system which aims to «“scramble” user passwords». It's meant to be attached to servers that verify user credentials, and replaces techniques such as storing plain text, encrypted, hashed, HMACed or bcrypt-ed passwords in a database.

The problem they want to solve is that of hackers who break into a system, dump the password database and manage to recover some or all of the passwords. The last year alone, hundreds of millions of credentials have been stolen and leaked online, and a significant amount of those have been recovered by hackers / researchers. In light of this, the case of the poor password storage is a problem worth solving.

So it's not that their effort isn't a noble one - it really is. There's just that:

  1. Solving the problem sufficiently does, for the most, not require any special hardware.
  2. People are bound to believe that this solves problems that it really doesn't affect at all.

Why not bcrypt?

The team behind the S-CRIB has published a reasoning for «why not to use bcrypt»:

BCrypt is a special cryptographic algorithm (a key derivation function) that is on purpose very slow. [..] We don't like this blunt approach as it assumes known ratio between computational power of “business system” and attackers.

In essence they are arguing that many cloud servers are slow, and that common bcrypt configurations therefore require relatively cautious settings to provide decent performance. Bruteforcing passwords with the same bcrypt config, on a cluster of very powerful computers, will inevitably burn through more passwords per second.

In other words, they seem to be fine with bcrypt in itself, but are worried that running bcrypt on slow servers will promote more or less insecure configurations.

And to solve this, they suggest replacing bcrypt entirely, with specialised hardware setup for key derivation. In the post above, that specialised setup is a combination of (clustered) Raspberry PIs and hardware dongles.

I'm not immediately fond of the idea of replacing a time tested algorithm (bcrypt) with layers and layers of relatively untested hardware and software. That goes for the hardware dongle itself, the Raspberry PI and the software running on the PI.

While somewhat unfair towards a product that's still in the testing phase, I want to pull out this example from the S-CRIB web service code.

@route('/SCRAMBLE/<apikey>/<password>/<saltlength>/<salt>')
@route('/SCRAMBLE/<apikey>/<password>/<saltlength>')
def scramble(apikey = '', password = '', saltlength = '', salt = None):  
    command = "SCRAMBLE"
    try:
        checkRemote(command, request.remote_addr)
        password = password.strip()
        saltlength = saltlength.strip()
        int(saltlength, 10)
        saltlength = '%02d' % int(saltlength, 10)
        apikey = apikey.strip()
    except ValueError,e:
        text = "%s"%e
        print(text[6:])
        return text[:6]
    if salt is None:
        received = forwardRequest(command + " " + apikey + " " + password + " " + saltlength + "\n")    
    else:
        received = forwardRequest(command + " " + apikey + " " + password + " " + saltlength + " " + salt + "\n")    
    return received

Client applications will call the above web service with a user supplied password, along with an optional salt. The dongle will process the input, and return an encrypted value to the client. This value is what the client application will check against its database.

Do you happen to notice how the password and salt is passed on to the dongle? And can you imagine what will happen if you try to use a password which contains a forward slash, space, tab or various other more or less special characters? It'll break.

These are simple problems to fix, but also terribly simple problems to avoid in the first place. When reviewing software like this, alpha, beta or whatever you'd brand it, I'd expect to see tests for this sort of thing. Preferably also something with fuzzed input, to see how the entire stack handles both weird data and high load. I've found no such thing in the S-CRIB repository.

Stick with what's available, for now

I'm not saying that the's no future for the S-CRIB Scrambler, nor that it isn't a solution to the problems presented initially. I'm sure it can be.

What I am saying is that while it isn't by any means an immediate solution, immediate solutions do exist:

  • To solve the problem of plaintext or weakly hashed passwords, use bcrypt or scrypt.
  • To reduce the risk posed by weak configurations on slow servers, use dedicated, faster, servers to do process passwords.

For the absolute majority, this will be more than enough. And certainly much better than using RC4 as Adobe once did for millions of their passwords! Everyone else should consider lending a hand to improving the S-CRIB Scrambler (and other solutions).

A final note on what this isn't

A short while after the scrambler gained international attention, I noticed articles popping up on how this solves the issue of complicated passwords and passphrases.

Simply put, it doesn't.

The S-CRIB Scrambler, as with any other decent server-side password storage facilitation mechanism, only ensures that passwords are stored with reasonable security. It's still not ok to use four-letter passwords. And it's certainly not ok to use the same password on all services.

If client side password security, or even remembering passwords, is a concern, use password managers such as LastPass or 1Password.