What take a loot at when use password-based authentication in software development

1. January 2016
Flaws of password-based authentication
by Igor Sobinov

2. 2
Agenda
• Overview
• Vulnerabilities
• Where to find errors
• Testing Techniques
• Defense

3. 3
Password-based authentication
• User-side issues: People don’t like passwords because it is need to invent new one for
every service, remember the whole bunch or store somewhere
• Administrator-side issues: Password difficulty should be enough to prevent brute force,
but not too hard because users could write it down and stick to the monitor. The worst
case if user forget the password

4. 4
Vulnerabilities
• Password Compromise: password is a single-factor authentication method. Password
could be tricked (phishing), bribed (chocolate) or coerced
University of Luxembourg: 43.5% users exchange password for chocolate (2016)
Keysniffer vulnerability opens wireless keyboards to snooping (2016)
• Allowing Weak Passwords: blank, password (for Non-native English), user name.
Password re-usage is also in loop
FBI's most-wanted cybercriminal used cat's name as password Chewy 123 (2014)
• Password Iteration: EmmaSummerPassword01, EmmaAutumnPassword01
25%-33% users iterate passwords.

5. 5
Vulnerabilities
• Not Requiring Password Changes: Ones been compromised will remain compromised
indefinitely
• Default Passwords: The No1 to check in hacker’s list
Cash register (POS) maker used same password 166816 for 25 years (2015)
The Launch Code for U.S. Nukes Was 00000000 for 20 Years (2013)
• Replay Attacks: Network traffic is obtained and used to have access as real user. Public
Wi-Fi is the most often place

6. 6
Vulnerabilities
• Storing Unencrypted Passwords: how?
Starbucks: We Stored Your Passwords in Plaintext (2014)
Chrome saved passwords in plain text (2013)
• Storing Encrypted password:
Far, The Bat, etc.
Windows 8 Stores Logon Passwords in Plain Text (2012) ???
• Brute force Attacks: Use salt, use enough computing resources
LinkedIn started use salt after 2012 hack

7. 7
Vulnerabilities
• Revealing info in case of failure: don’t inform what’s incorrect: user name or password.
Prevent time attack:
bool login(String User, String Password)
{
if(!userTable.contain(User))
return false;
return HASH(userTable[User]) == HASH(Password);
}
CVE-2016-6210: OpenSSL timing attack BLOWFISH <-> SHA256/SHA512

8. 8
Vulnerabilities
• Online Attacks: Unlimited try, no account locks???, DDOS. Strong CAPTCHA. Slow down
the authentication mechanism for repeated failures.
Find my iPhone vulnerability (2014)
• Return a forgotten password: don’t return originals, generate new one.
Don’t send password via email
Uber send plaintext passwords in emails (2015)
Google says half of email is sent unencrypted (2014)
• For clients: Trusted DNS names (DNSSEC), secure channels (TLS)

9. 9
Where to find errors
• Password Compromise: Don’t store passwords as clear text, use substitutes
• Allowing Weak Passwords: Check the complexity requirements. Check localization
• Default Passwords: Reset at first login. Limited functionality.
Windows XP: if administrator password is blank it can’t be used across the LAN
• Replay Attacks: Don’t invent protocols. Use encrypted channel.
NTLM isn’t susceptible but NTLM over HTTP is susceptible (2005)

10. 10
Where to find errors
• Brute Force Attacks: Use well-designed key derivation function(KDF). Take a look at RFC
2898, PBKDF2. Pay attention to number of iterations
• Online Attacks: Account lockout for configurable number of attempts, configurable
duration, revealing failure to the user name or password, timing attacks

11. 11
Testing Techniques
• Password Compromise
• If password asked during setup, check for temporary files after setup. Break setup
by incorrect parameters or process kill
• If application create locked temporary files with secrets, create hard link to them
• Test binary and memory dump of application for default accounts
• Process memory could be crowding out to swap. Memory eater.
• Replay Attacks
• Capture the authentication traffic and sent it again
• If SSL/TLS used, setup MITM proxy and check if application notices about self-
signed certificate

12. 12
Testing Techniques
• Brute-Force Attacks: check for brute-force password speed of typical CPU. Good limit-
no more 100-200 per second. Modern GPUs are massively parallel
• Check access rights to the password database

13. 13
Defense
• Any ways to avoid passwords?
• Password Compromise
• Educate users
• Don’t store plain text passwords
• Don’t store password in process memory longer than required, use bzero
• Logon page should be only accessible via SSL/TLS

14. 14
Defense
• Weak Password
• Enforces password complexity and length requirements
• Microsoft: minimum 14 symbols (2016)
• NIST: minimum 12 symbols in 95 symbol alphabet (printable ASCII)
• All available symbols: A-Z a-z 0-9 ~-& ◙ ╜┐╗♠. Be aware of SQL DBMS
• Randomly where feasible
• Increasing the length of the password by only 2 characters gives 500 times more
variations than the increase in the alphabet of 18 characters.
• Parts of user name mustn’t be contained, but only long enough
• Dictionary words ???

15. 15
Defense
• Iterated Password: change all variants of numbers and slightly change other symbols. If
previous derives, drop the variant.
• Password Change: Set the minimum and maximum password age.
High security systems by Microsoft: 7-30
Use password history
• Default Password: Don’t use default password.
If it is required, put system in lock-down mode and don’t allow remote logins
• Store password in protected databases

16. 16
Defense
• Replay Attack: Use SSL/TLS or IPSec. Use Secure Remote Password protocol (SRP) that
don’t send password over the network (implementation of Zero-knowledge proof)
• Password Verifier: Use good KDF, like PBKDF2, bcrypt, scrypt.
Number of iterations
• RFC 2898: 1000
• Office 2007: 50000
• Office 2010: 100000
Salt
• RFC 2898 8 bits, better 16
• Must be random
Hash
• HMAC-SHA256

17. 17
Defense
• Classical key exchange protocols required PKI or trusted third party to prevent MITM
attack.
• Password-Authenticated Key Exchange (PAKE) is a technique that aims to establish
secure communication between two remote parties solely based on their shared
password
• PAKE by Juggling (J-PAKE) is a PAKE implementation achieves mutual authentication in
two steps:
• first, two parties send ephemeral public keys to each other
• second, they encrypt the shared password by juggling the public keys in a
verifiable way
The idea is to replace the low-entropy password with high-entropy cryptographic
key. Due to it J-PAKE has off-line dictionary attack resistance

18. 18
Defense: Diffie-Hellman
a, b {1, … q-1}

19. 19
Defense: PAKE

20. 20
Defense
• Online Brute-Force Attack: Don’t disclosure user names.
• Account lockout: temporary or permanently.
• Graduated timeouts: attempts per second
• CAPTCHA
• Forgotten Password reminder: Don’t send previous password, generate new one.
• Don’t send the password at all, ask user to enter it on site
• Secure questions shouldn't contain public information
• Two-factor authentication (2FA): NIST don’t recommend to use SMS (2016) due to
phone number could be attached to VoIP or hijacked. Use biometric methods.
• Оппозиционные активисты пожаловались на взлом аккаунтов в Telegram (2016)
• One time passwords: On public places passwords could be easily stolen.

21. 21
Examples: Real Story
Paris Hilton
Socialite
Heiress of Hilton empire

22. 22
Examples: Real Story
Paris Hilton T-Mobile cell phone was hacked via web access to cloud (2005)
Ways to protect password-based account:
• Restrict logins to specific locations (states, countries)
• Disallow logins from Tor and other darknets
• Set up two-factor authentication
• Restrict access for specific devices (UUID)
• Log off automatically
• Create one-time passwords to log in from untrusted computers
• Divide: account name, user name, email

23. 23
Q&A