[Cryptography] Why don't we protect passwords properly?

Krisztián Pintér pinterkr at gmail.com
Tue Dec 24 19:37:55 EST 2013


Bill Frantz (at Wednesday, December 25, 2013, 12:27:29 AM):

>>one could also ask how safe it is to sprinkle the secret all over the
>>RAM, increasing the risk of getting swapped to disc, or being
>>recoverable by cold boot attack.

> I must say, these attacks don't seem to be common. Are there any 
> examples of these attacks being used in the real world?

one day an attack is not common, the next day it is. you probably
would have said in 1980: cache timing attacks are not common. just as
virtually anybody else said. but in 2013, there is a great interest in
timing-resistant AES implementations.

attackers will use whatever they can. and i'm betting a thousand bucks
on filling the RAM with sensitive data will be an attack vector sooner
or later.

> The cold boot attack goes away if you leave your device off

it is not satisfactory to list the situations in which an attack is
not feasible. we want to know when it is. furthermore, we want
primitives not sensitive to attacks. i'm happy that you can turn your
laptop off before approaching airport customs. but there can be people
that can't avoid some situation in which a cold boot attack is
possible.

> Swap encryption is the sweet spot of cryptography

swap encryption is nice, but attacks against memory are not limited to
that. RAM is shared on HW level between CPUs, very hard to protect on
a VM, data travels on the bus which emits EM, etc. it is also a hot
topic to do encryption inside the CPU.

> These attacks pale into insignificance compared with the know
> attacks on passwords.

i would agree that these are less important issues than password
stretching. however, they are not contradictory. i can design a kdf
right here that does not leak the password all over RAM, does not
index or branch on secret, but does use a lot of RAM and CPU. the
downside of my design would be not being sequential memory hard, and
having a 20-40% additional CPU load compared to an unprotected
implementation (as the attacker will most certainly implement). this
is quite significant, but it is arguable whether it is more
significant than the upsides. but i trust better minds can create a
solution with the benefits from both worlds.






More information about the cryptography mailing list