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.

def scramble(apikey = '', password = '', saltlength = '', salt = None):  
    command = "SCRAMBLE"
        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
        return text[:6]
    if salt is None:
        received = forwardRequest(command + " " + apikey + " " + password + " " + saltlength + "\n")    
        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.

Don’t trust Instagram on shared wireless networks

Over the last decade, wireless networks have been a prime target for hackers. The ability to sniff out traffic belonging to others, and with it any unencrypted credentials or other valuable information, is what drives them. Because of this, most popular services today, such as Twitter, Facebook and Gmail, have moved to HTTPS for all authenticated communication. Instagram, however, lags behind.

Consider who the users are

To the security minded, this may not come as much of a surprise — another social media service that fails to provide basic protection, nothing new there.

What makes this one different to me, though, is who many of the actual users of Instagram are, and where they use the service from: Kids, in schools.

Many parents allow their children to use Instagram on the condition that they protect their profiles. By protecting an Instagram profile, only those added as friends may view the owner’s profile and pictures.

Some use Instagram for the sole purpose of gaining exposure, and that’s fine. For others, though, and especially the young, this can attract attention from the wrong kind of crowd. Getting attention from people you don’t know or trust can lead to anything from a young girl getting her pictures uploaded to a pornographic site, to someone in a van pulling a young boy in through the side door.

instagram secure

The problem

Whenever you bring up your phone, connect it to the corporate / coffee shop / school wifi and open the Facebook app, all relevant communication with Facebook’s servers will be encrypted. Even on public and unprotected wireless networks, this means that an attacker can’t realistically decode what’s being sent and received.

With Instagram, this isn’t the case. Sure enough, editing your profile will take you through an encrypted connection, but browsing the image stream and looking through the pictures you and your friends have posted, is not encrypted. This means that anyone on the same wireless network may capture this communication and steal key pieces of it. These key pieces can be used to bypass authentication, and let the hacker browse Instagram through the victim’s account, on the hacker’s own computer.

Recommended action

Until Instagram makes HTTPS the default for all interaction with their servers, or at least an opt-in setting, it’s use should be avoided through shared wifis.

Using it via the mobile network, e.g. 3G/4G, is (relatively) safe, but that does come with increased costs.

Technical brief

This really is your run-of-the-mill session hijacking vulnerability, but I’ll describe it real quick for good measure.

When you open the Instagram app, a request such as the following is sent to their servers:

GET /api/v1/feed/timeline/? HTTP/1.1  
Accept-Encoding: gzip, deflate  
Accept: */*  
Cookie: csrftoken=[...]; ds_user=einaros; ds_user_id=[...]; sessionid=[...]; mid=[...]  
Connection: keep-alive  
Accept-Language: en  
User-Agent: Instagram 4.1.3 (iPhone3,1; iPhone OS 6_1_3; nb_NO; en-GB) AppleWebKit/420+  

Bringing these cookies into the browser, and opening the same url, yields an error reading This, this page could not be found.

Looking closer at the sessionid cookie, it contains a setting which seems to indicate that the platform the session is active on is a phone. So, what happens then if you replace the User-Agent of your browser with e.g. that of an Android client?

Well, you’re allowed entry.