SAuth: Protecting User Accounts from Password Database LeaksGeorgios Kontaxis, Elias Athanasopouls, Georgios Portokalidis, 

Angelos D. Keromytis

Presented By:Richie Noble

   

Password Use

● Dominant form of access control

● Password theft on the rise– Annoyance, financial 

damages, data loss, privacy loss

http://core0.staticworld.net/images/article/2013/01/password_580­100022344­large.jpg

   

Password Security Problems

● Password Security– Should be complex– Never written down– Changed frequently– No password reuse– Verify website authenticity

● Passwords are still being stolen

   

Criticism of Passwords

● Alternative authentication methods– Public­key mechanisms– Graphical passwords– Single­sign­on service

● OpenID, OAuth● Single online identity● Present single point of 

failure

http://www.blugraphic.com/wp­content/uploads/2012/06/Sign­in­With­Facebook­Twitter­Buttons­Dark.jpg

   

Criticism of Passwords (Cont.)

● Two­factor authentication– Requires an additional 

password for authentication

– High overhead in cost and deployment effort

– Scales poorly for multiple services

– Leads to weaker passwords

http://i.stack.imgur.com/Qt7zy.png

   

Synergetic Authentication (SAuth) 

● Framework employing synergy between sites– To log into service S you are required to authenticate 

with vouching service V● Founded upon the way most users access the web● Works on top of already existing authentication 

procedures● Decoy passwords to tackle password reuse

   

Outline

● Introduction● Background● SAuth Architecture● Implementation● Password Reuse● Security Evaluation● Conclusion

   

Background

● Passwords more popular than ever

● Application procedure– Salt is added to plain­text 

password– Hash function used to get 

password digest– Stores salt and digest in 

database

http://2.bp.blogspot.com/­wawdKoGwItI/T9in0R5AKDI/AAAAAAAAB­A/4mXQLLffTB0/s1600/username.gif

   

Password Leaks

● Exfiltration of user passwords stored in a database● Occurring roughly once every couple months

– Twitter, LinkedIn, Sony...– Malicious insiders– Front­end bug exploitation (e.g., SQL injection)

● Even diligent users may have password compromised

   

Password Cracking

● Cracking methods– Brute­force attack– Dictionary attack– Hybrid combination

● Permutation of dictionary words to crack passwords meeting bare minimum security requirements (e.g., password1)

● Increased processing power– Parallel architectures in GPUs

● Cracked 8­character­long NTLM passwords for Microsoft Windows in just five hours

– Cracking platforms using resources of the cloud

   

Password Cracking (Cont.)

● Alternative hashing functions– MD5, SHA1

● Fast and efficient, favors attackers who have leaked database

– bcrypt, scrypt● Tuned to take constant time

● Authors assume that any leaked password will eventually be cracked

   

Outline

● Introduction● Background● SAuth Architecture● Implementation● Password Reuse● Security Evaluation● Conclusion

   

SAuth Architecture

● Logging in to service S requires authenticating with vouching service V– An attacker must compromise both accounts' 

passwords– Stored in separate databases for each service

   

SAuth Architecture (Cont.)

● Alice has an account A­>S on web site S● Alice has an account A­>V on web site V

   

SAuth Activation

● Logging in to vouching service V is not enough– Bob's account B­>V 

cannot be used as proof of authentication for service S

– A­>S and A­>V must be associated when SAuth is initially activated.

   

Security and Trust

● S trusts that V is working properly when receiving vouching token

● Security procedures of S take precedence over the ones of V– If V is unavailable or insecure, security process is 

as if SAuth is not in place at all– Including more vouching services increases 

redundancy

   

Authenticity

● Special measures required to ensure authenticity of messages

● Each protocol message carries the service, signature, and signed_fields parameters– service identifies sending service– signature is an encryption of the rest of the parameters– signed_fields is a list with the names of the encrypted 

parameters

● A nonce is generated per message to prevent replay attacks

   

Password Reset

● Generally, may ask security questions before receiving an email to reset password– Form of synergy­based authentication

● Under SAuth, user must authenticate under vouching service before proceeding– Couples with existing procedure

   

Usability● SAuth is founded upon existing browsing habits of users

– Does not affect web experience

● Users maintain many tabs concurrently● Sessions in online social networks tend to be long­lived● Cookies are used to maintain sessions

– If a vouching site is already logged into, a user will not be interrupted when logging into an SAuth enabled site

● Vouching services chosen due to popularity and dependability– Users will almost always already have an account with a vouching service

● Users can add their own vouching service● Opt­in

– Users can defer to activate SAuth

   

Password Compromise Alerts

● SAuth enables a warning system for when passwords are compromised– Failing to authenticate at vouching site after 

successfully doing so at target site

● Allows catching of anomalous activity that would otherwise go unnoticed

   

Outline

● Introduction● Background● SAuth Architecture● Implementation● Password Reuse● Security Evaluation● Conclusion

   

Implementation

● SAuth protocol messages defined as URIs– Works with any URI­oriented protocol (e.g., HTTP)

● Two groups – registration and authentication● Target site and vouching site must be aware of each 

other's endpoints– Can be exchanged offline or through XML file (sauth.xml)

● Implemented in PHP– Less than 1000 lines of code

   

Registration

   

Authentication

   

HTTP User­agent Redirection

   

Outline

● Introduction● Background● SAuth Architecture● Implementation● Password Reuse● Security Evaluation● Conclusion

   

Password Reuse

● SAuth is rendered moot if a user is sharing the same password across multiple sites– Common in practice – password is reused six times on 

average

● Intensifies the problem of password leaks● Password managers could solve problem

– Offered natively by web browsers– Usability issues obstruct widespread adoption

   

Decoys

● Decoy passwords in databases introduce uncertainty about the actual password

● Every user has N passwords instead of one– Any can successfully authenticate the user– Carry no special marks or special treatment– Increases password space of vouching site, not 

target site

   

Decoy Generation

● Decoys generated by identifying context of password and randomly producing tokens to match it– No single mask to describe set of passwords– Use weights instead of random generation to produce more 

human­like passwords

● Passwords grammatically decomposed– Substitutions such as “leetspeak” used (e.g., p@55w0rd)– Generate parts of speech tags

● “she runs fast”   “pronoun verb adverb”   “she plays carefully”→ →

   

Outline

● Introduction● Background● SAuth Architecture● Implementation● Password Reuse● Security Evaluation● Conclusion

   

Security Evaluation

● Evaluation accounts for SAuth coupled with and without decoys– Trade offs – Too many decoys makes it easy to guess target site's 

password, too few make it easy to guess vouching site's password

● We consider the probability of two events– Gb  for someone guessing both passwords

– Gs  for someone guessing the second (vouching site) password

● D(s) is the distribution of users that reuse passwords for both target and vouching service (~70%)

● PS = Password space

   

Security Evaluation (Cont.)Probabilities without decoys

   

Security Evaluation (Cont.)Probability with decoys (K1 and K2)

   

Decoy Set Size

● Expanding decoy set makes guessing easier for attacker with no password reuse

● Given 70% probability that a password is reused and with a PS of 948 ([a­z][A­Z][0­9] and symbols)– Decoy set should be 944  decoys per user

● Any less, attacker would prefer to guess among leaked decoy set

● NIST Level 1 – 1,024 decoys per user

● NIST Level 2 – 16,385 decoys per user

   

Conclusion

● SAuth is a novel protocol for synergy­based enhanced authentication– Based on user behavior, remains mostly 

transparent– Works as extension of existing authentication 

methods, not a replacement

● Decoy passwords employed in databases to mitigate password reuse practices