Info Sec • I like shapes • 20 Years young – So no beer – I accept protein shakes • Hacker | Dreamer | Idealist • Where? – https://bitbucket.org/Zaeyx/ – http://twitter.com/zaeyx – In your deepest, darkest dreams
– Why we can’t trust humans to secure things • The Philosophy – Secure by default • The Solution – The logical overview – Technical Implementation • The Future
Augusta – Stored Password Security… • Plaintext / Encoding – 1 step from disclosure • Encryption – Key must be accessible – Only prevents a one-step attack • Hashing (fast) – Cracking is too easy – Users create minimal complexity passwords • Adaptive Hashing (slow) – Harder, but still possible • Computational power war
a seesaw – Between algorithm strength & password strength • Fast hashing requires stronger passwords because the algorithm is weak • Slower hashing allows for weaker passwords – Bad assumption: “This is harder, therefore I win” – Strength comes from computational difficulty algorithm password
and Pop (victim) – Supporting a service that has to compute constantly (logins) – Harder computations result in a greater cost (uptime, resources, etc.) • Russian Mob (attacker) – One objective: crack the hashes – Only has to attack each hash once – Can distribute the cracking – Can build a powerful machines uniquely designed to crack M&P’s algorithm • The attacker will always have the computational advantage
assumptions • We have to assume the worst case scenario • We have to assume, the attacker is a dedicated, nation state, ready to handle our hashes • We have to assume that we have limited resources resulting in a system where the hashes and the passwords aren’t that strong (our seesaw is broken) • Then we build up from that terrifying picture.
money just so you can compute slow algorithm logons for all your users • Users don’t want to use a 25 character alphanumeric + special, passphrase • You don’t want to enter into a computational power war with a nation state or criminal group running botnets
things – We need to identify and exploit a defensive advantage – We need to make passwords easy for users • Well really, three things – People smart enough to figure out need #1 while considering need #2
internet is broken – We are fighting a war – One that we are losing – One that we cannot afford to lose • Without empathy we are just solving puzzles – We need to find and solve issues that matter
We must build our systems to be secure by default – We need to make the users lives easier not harder – We need to stop relying on users for our security • I want to make passwords fun again
Is no problem for an attacker – In fact, it’s very hard to stop this • What about downloading a ton of data… – What if the attacker needed terabytes of data? – What if our outbound pipe was only so large? – What if it was monitored for huge downloads? • (note: monitoring isn’t necessary, just helpful)
on the network • We tie authentication to this file • To check if a password is valid or invalid – You need the stored password representation – And you need this huge file • If the attacker gets the stored password – He still needs the huge file to make a single guess
– Passwords become easy – It basically protects itself • Offline password attacks will go extinct • It’s cheap to implement • It scales with your business
weight tying down the attacker • Because – He has to extract it from the network – Distributing it is a huge pain – Loading it to a cloud cracking service is out – Hosting it for others nets bandwidth issues – It’s loud and clunky and easy to track
of random data • Pull some data from that array • Store that data as our message • Anything that goes into the block cipher – Will be 100% random – Will be delimited by length – Will be deterministically confirmable as ours
– Create the array – Store a password – Perform authentication • Once I’ve explained all this – We’ll go over a few specifics and shortfalls – I will be addressing all this in the whitepaper
talk a little about this at the end • Use either true random • Or a CSPRNG with a strong seed – And THROW OUT THE SEED • The attacker must not be able to expand the array from a simple seed
pairs • We need to split by type and concatenate – Pointers together – Data together Ptr_0, Data_0 Ptr_1, Data_1 Ptr_2, Data_2 Ptr_3, Data_3 Ptr_0Ptr_1Ptr_2Ptr_3 Data_0Data_1Data_2Data_3
the data – Use a secure hashing function like Sha3 (Keccak) • It can be a fast hashing function though • (Note: for some of this, collisions work in our favor) • Concatenate the pointers and the hash • So now we have: Ptr_0Ptr_1Ptr_2Ptr_3Sha3(Data_0Data_1Data_2Data_3)
data aren’t already binary • We have to do this because – Invalid decryptions don’t come out just as ASCII – They range the entire character-space • As binary data BinaryOf(Ptr_0Ptr_1Ptr_2Ptr_3Sha3(Data_0Data_1Data_2Data_3)) Warning: This must be done properly, simply translating ASCII to binary isn’t good enough
the binary data with AES – Use the user’s password as the key User’s Password: Sha3(MONSTROSITY) BinaryOf(Ptr_0Ptr_1Ptr_2Ptr_3Sha3(Data_0Data_1Data_2Data_3)) AES-128_CTR Random Nonce
the binary data with AES – Use the user’s password as the key User’s Password: Sha3(MONSTROSITY) BinaryOf(Ptr_0Ptr_1Ptr_2Ptr_3Sha3(Data_0Data_1Data_2Data_3)) AES-128_CTR Random Nonce Password Representation: 8fda158e42aef96062fe1ac0ecd8a83f
stored data with it User’s Password: Sha3(MONSTROSITY) Random looking output: 01110011011101000111001001110101011001110110011101101100011001010000110100001010 AES-128_CTR Random Nonce Password Representation: 8fda158e42aef96062fe1ac0ecd8a83f
for – Length of each pointer – Length of each data section – Length of hashed data – Number of pointers • Use these to split your output into variables Ptr_0, Ptr_1, Ptr_2, Ptr_3, Sha3(Data)
go get its paired data – Obviously you need the array for this – This is the step at which the attacker fails without • Once you have all the data – Throw out the pointers – Concatenate the data Data_0Data_1Data_2Data_3
– The data length is the amount of the data to be pulled from the array at the randomly chosen location – You want to choose enough entropy so that the chances of a successful decryption without the proper key is statistically impossible – If your data length is 128 bits, the chance of a collision is 1/(2^128) for every key • Though, that actually stacks really fast when we’re using multiple pointers
your array – You want it to be large enough so as to be infeasible to extract any significant portion of it – Pointer considerations must be made • Depending on the format you choose for your pointer • This is because if the amount of viable pointers to the array max out before the pointer-space does the attacker can determine some of what the password IS not. – Allow me to explain
viable indexes 0,1,2,3 • If in your pointer|data pair, you use a single decimal character to represent the pointer.. – You get decryptions that give an pointer outside of the array 4,5,6,7,8,9 • It is infeasible to steal the array • But easy to figure out what the highest index is
some of what the password isn’t • He does this by making guesses • If the decrypted pointer is outside of the array, he knows that is not the password – Because it’s is impossible to confirmable
is minimal – It won’t reveal the password 2. Match your pointer-space and array size – Limits your possibilities 3. Use non-sequential indexes – You could create a mapping too large to steal – This could quickly get out of control 4. Make indexes wrap around – Just do pointer = temp_pointer % sizeOf(array)
an attacker can get away with just stealing part of the array • It’s incredibly important to hash the data though • If you don’t, you make his job easier – Only needs to see one pointer|data pair – Since the chances of a collision are astronomical
Anti-automation mitigation – Monitoring and defense – Who has 4 char passwords in their dictionary? • Offline attacks – openBAC • 1234 == *Secure* password
• Our objective isn’t necessarily about convincing everyone to implement BAC • It’s about pushing the industry forward • Market research shows that given several options, people choose the “in between” option because of the perceived “best of both worlds” • Goldilocks Principle
– BAC (too complex / costly) – Fast Hashing (too insecure) – Adaptive Hashing (juuuuust right) • This is still a win, but we need to change the trajectory • BAC is a real solution, and a step in the right direction
Discussion/Development • https://twitter.com/zaeyx – For my latest ramblings on the subject – Watch here for the release of the full whitepaper @zaeyx | @lanmaster53
yamahiro
doradora09
poteboy
nina01
yhana
saramune
shoota
foursue
layerx
taishin
wmsbill
ryysud
productmarketing
chriscoyier
robhawkes
malarkey
aki_iinuma
kneath
cassininazir
holman
lara
danielanewman
sugarenia
sferik
