

To Keep Passwords Safe from Hackers, Just Break Them into Bits - newscasta
http://www.technologyreview.com/news/429498/to-keep-passwords-safe-from-hackers-just-break-them-into-bits/

======
tedunangst
If LinkedIn, the article's whipping boy for bad password storage, had somebody
with the brains and capability to purchase and integrate this multi-machine
password storage system, LinkedIn would have had somebody with the capability
of implementing a secure password hashing system like pbkdf or bcrypt or
scrypt and wouldn't need to buy a mega priced security solution from RSA.

~~~
fleitz
All they needed was someone with the intelligence necessary to type:

gem 'devise'

into a textfile.

~~~
lawrencepit
Sure thing:

Security announcement: Devise v2.2.3, v2.1.3, v2.0.5 and v1.5.4 released

[http://blog.plataformatec.com.br/2013/01/security-
announceme...](http://blog.plataformatec.com.br/2013/01/security-announcement-
devise-v2-2-3-v2-1-3-v2-0-5-and-v1-5-3-released/)

~~~
fleitz
Upgrade immediately unless you are using PostgreSQL or SQLite3.

So using a real database mitigated the entire issue. Secondly, this security
issue doesn't allow you to retrieve every user's password in 8 hours.

------
meritt
Someone needs to show these guys Stripe CTF 2.0 Level 8.

[https://github.com/stripe-ctf/stripe-
ctf-2.0/tree/master/lev...](https://github.com/stripe-ctf/stripe-
ctf-2.0/tree/master/levels/8)

~~~
jarin
Haha, this is the first thing I thought of when reading this article.

In reality, it would probably be difficult to execute on a live production
server via the TCP port method. The artificial delay they added in to prevent
timing attacks might cause a heavy load on the server, so if they leave that
out that would be another possible attack vector.

~~~
webreac
I enjoyed a lot stripe 2.0 and I have watched Dan Bone on coursera. In the
article, they just split the password in two. 128bit/2 -> 64bits. This remains
two much for brute force like TCP port method or timing attack.

------
rogerbinns
I'm confused by their logic. Customers are those who are unable to keep one
set of servers appropriately secured and unable to mitigate compromises
through the use of better techniques (eg bcrypt).

So the solution is to run a second set of servers. Why would those be any
better or differently secured?

~~~
michaelhoffman
Because this method makes RSA some money?

~~~
Create
sudo apt-get install ssss

or

sudo port install ssss

------
rdl
Threshold cryptography might be an interesting approach when you _need_ to
keep credentials (vs. hashes of credentials), but I'd probably go with keeping
my credentials encrypted under keys stored in a hardware security module (HSM)
with rules on access (rate limit, etc.), first. Vastly cheaper (even though
HSM prices are generally a form of rape), and simpler.

------
alanctgardner2
I like the little plug at the bottom for physical OTP devices, which
completely neglects to mention that RSA is a leading player in this space. I
wonder if the writer accidentally went the completely wrong direction with
that sound bite.

------
fulafel
Sounds a bit like "envaulting":
<http://en.academic.ru/dic.nsf/enwiki/10223648>

This is from a crypto startup called Envault that was founded on the idea of
splitting data in pieces - they keep a fraction of the ciphertext somewhere
"in the cloud" and off the local storage of your device when not in use. This
is advertised as being very very safe.

I never heard any crypto guy with credentials comment on their tech though
which is usually a bad sign...

------
jiggy2011
Can't you just use bcrypt/scrypt and be done with it?

~~~
fleitz
That's really the sad part... technically it's a superior solution to
bcrypt/scrypt but the reason why LinkedIn got pwned was because they MD5'd
their passwords instead of bcrypt/scrypt.

~~~
lonnyk
If I remember correctly they were also not using a salt. They stated that
"members whose passwords have not been compromised benefit from the enhanced
security we just recently put in place, which includes hashing and salting of
our current password databases."[1]

[1] [http://blog.linkedin.com/2012/06/06/linkedin-member-
password...](http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-
compromised/)

~~~
jarin
It blows me away that nobody at LinkedIn had heard of rainbow tables, or that
they didn't think it was THAT important.

~~~
jrockway
The problem is that when you make this mistake early, it's not easy to fix,
since you don't have the passwords yourself. Though I guess they could have
rainbow-table'd their own password database and migrated everything over to a
better scheme, rather than waiting for users to successfully log in.

~~~
moxie
It's not really that difficult. Let's say you've got a column called
'insecure_pass' that is storing a simple md5 hash of users' passwords.

Four simple steps:

1) You add a new password column to your DB (secure_pass) and modify your
account creation / password change code to store bcrypt(md5(password)) in that
column in parallel with just md5(password) in the old insecure_pass column.

2) You run a job that migrates insecure_pass to secure_pass by calculating
bcrypt(insecure_pass) and storing that in secure_pass.

3) You turn on "dark reads" for secure_pass on login and log if there are any
cases where validation against secure_pass failed when validation against
insecure_pass succeeded. If a log message shows up, you did something wrong.

4) You move over to "light reads" for secure_pass and stop updating/validating
insecure_pass. Once that's deployed, you drop the insecure_pass column from
your DB.

~~~
jrockway
That's a really good idea. If you can't protect the passwords, you can at
least protect the hashes, with almost no loss of speed or security.

------
jpallen
No doubt I'm missing something dumb, but would one get similar benefits from
simply storing half of the password hash on one server, and half on the other?
To authenticate the password, you would then just authenticate it against both
servers which can tell you whether their half matches. What is the advantage
of the technique described[1] in the article compared to this?

[1] That's putting it a bit kindly. 'that we were told exists' might be more
fair.

------
jlkinsel
Yeah...this is nice, but really who's gonna implement it? Only folks with a
lot of resources and need to protect something more serious than passwords on
a social network.

Or organizations who are vulnerable to the RSA sales person attack. ;)

As others have hinted - once you have folks sophisticated enough to do tricks
like using multiple operating systems, you'd hope they're going to catch the
basics...

~~~
Shorel
I believe that in some future time the password of a social network will be
one of the most important passwords a person can have.

You can change banks easier than you can migrate all your contacts to another
social network.

------
jrockway
"Hi Alice, this is Bob from Ops. Can you reset the root password on storage-
server-A and storage-server-B? The ticket is PCR-1337. Thanks."

~~~
jlkinsel
In theory if your'e going to the trouble of having different OSes on the two
systems, you'll have separate admin staff, as well...

~~~
uvdiv
In theory if you're going to the trouble of hashing your users' passwords,
you'll salt them too. None of us would be in this thread if these types of
theories were true.

------
EthanHeilman
I'd really like to know more. I've looked around and can't find anything. Can
anyone link to the paper they published on this?

~~~
amper5and
As I linked further down, this is probably based on Adi Shamir's (of R _S_ A)
threshold sharing scheme [1] [2]. Essentially, this approach splits any
"secret" into _n_ parts, requiring that _k_ of them are necessary to
reconstruct the original secret.

It relies on the fact that _k_ points are necessary to reconstruct a _k-1_
order polynomial. So if you hand out _n_ points, with _n_ > _k_ , then any _k_
of these points can be used to reconstruct the polynomial, whose _y_
-intercept is the "secret". The coefficients of the polynomial are random.

There are other [3] sharing schemes, and for the trivial _k_ = _n_ case,
Shamir's scheme is probably overkill.

[1] <http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>

[2, PDF]
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.8910&rep=rep1&type=pdf)

[3] <http://en.wikipedia.org/wiki/Secret_sharing>

UPDATE: Here are some links to RSA's "Distributed Credential Protection"
offering [4] and the white paper [5] describing it.

[4] [http://www.emc.com/security/rsa-distributed-credential-
prote...](http://www.emc.com/security/rsa-distributed-credential-
protection.htm)

[5, PDF] [http://www.emc.com/collateral/software/white-
papers/h11013-r...](http://www.emc.com/collateral/software/white-
papers/h11013-rsa-dcp-0812-wp.pdf)

------
afhof
Talk is cheap. Let's see the math.

~~~
amper5and
<http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>

by Adi Shamir, the "S" in RSA

------
rorrr
Security by obscurity.

