Upload
ngokiet
View
219
Download
2
Embed Size (px)
Citation preview
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_580100022344large.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– Publickey mechanisms– Graphical passwords– Singlesignon service
● OpenID, OAuth● Single online identity● Present single point of
failure
http://www.blugraphic.com/wpcontent/uploads/2012/06/SigninWithFacebookTwitterButtonsDark.jpg
Criticism of Passwords (Cont.)
● Twofactor 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 plaintext
password– Hash function used to get
password digest– Stores salt and digest in
database
http://2.bp.blogspot.com/wawdKoGwItI/T9in0R5AKDI/AAAAAAAABA/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– Frontend bug exploitation (e.g., SQL injection)
● Even diligent users may have password compromised
Password Cracking
● Cracking methods– Bruteforce 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 8characterlong 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 synergybased 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 longlived● 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● Optin
– 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 URIoriented 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
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
humanlike 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
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 ([az][AZ][09] 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