WHAT SHOULD WE DO?
• Securing your authentication infrastructure
• Use strong passwords and manage them
• Do what you want UNDER THE LAW
• HTTP is insecure
• Anyone can get plaintext passwords from captured packets
• The login form and endpoint should be delivered only via
HTTPS with valid certificate
• Basic auth over HTTPS is acceptable
• Use Digest auth for HTTP
MONITORING LOGIN FAILURE
• Check authentication logs
• Restrict maximum count of failures
• Fail2ban: http://www.fail2ban.org/
• Never store plaintext passwords
• glibc’s crypt(3) supports salted SHA-256/512
• crypt.crypt (Python), String#crypt (Ruby), crypt (PHP)
• Key Derivation Functions (KDF) are recommended
• relatively long time to compute
• hashlib.pbkdf2_hmac (Python, PBKDF2),
OpenSSL::PKCS5 (Ruby, PBKDF2), password_hash (PHP, bcrypt)
• scrypt: http://www.tarsnap.com/scrypt.html
IDENTITY AND ACCESS
• If you want the directory service,
→ Active Directory/LDAP
• If you use data of Twitter, Facebook etc.,
→ OAuth 2.0
• If the systems are various and large,
→ SAML/OpenID Connect
• Cloud solution: Identification as a Service (IDaaS)
TWO-FACTOR AUTHENTICATION (2FA)
• Combine password and card
• Random number table, Smart card
• Combine password and device implementing One-time password
• Mobile app (e.g. Google Authenticator), USB token (e.g. YubiKey)
• HOTP (RFC 4226), TOTP (RFC 6238)
• Combine password and biometric recognition
• Fingerprint, Finger vein, Iris etc.
USING STRONG PASSWORDS
AND MANAGING THEM
TYPE OF ATTACKS
• Attacking web services/servers
• e.g. SNS, Forums, EC sites, SSH servers
• Attacking specific person
• e.g. celebrities, VIPs, neighbors
• Brute force (including mask/hybrid)
• Hanako0101, Hanako0102, …, Hanako1231
• 123456, P@ssw0rd, letmein, qwerty, football, welcome, …
• Default Credential
• admin/admin, ubuntu/ubuntu, pi/raspberry, PlcmSpIp/PlcmSpIp, …
• Breached Credential
• Your breached Linkedin credential to Twitter, Facebook, iCloud, …
• https://haveibeenpwned.com/ 18
Don’t use predictable rules
Use unique passwords
Change default passwords
Use different passwords
HOW TO MAKE STRONG
• Is at least 8 characters long.
• Does not contain your user name, real name, or company name.
• Does not contain a complete word.
• Is significantly different from previous passwords.
• Contains characters from each of
USING MULTIPLE WORDS
• xkcd: Password Strength
• In my opinion, it is better
to use non-English words
EXAMPLE (DON’T USE THIS)
USING REAL SECRETS
• Actually, Azunyan is not my favorite character.
• Your real favorite items/celebrities/characters/phrases are
• i.e. weak against targeted attacks
• Choose the password that is safe even if others see.
• Systems may handle your passwords insecure.
• Classify services
• Bank / Public Services / SNS / Business / Oneshot
• Very important / Important / Moderate / Less important
• Use different passwords for different classes
• Adding prefix/suffix can be a mitigation for Breached Credential
• TAzunyanPeropero¥300!?, FAzunyanPeropero¥300!?, …
• Of course, the best is using completely different passwords
• Two-factor authentication
• Use as far as possible.
• Password manager
• Use if you want to.
• Periodically password change
• Do if you are forced to.
• Nobody can make it perfect. Do what you can do comparing cost
OBSERVING SSH ATTACKS
• Observed login trials on my SSH honeypot (58000 records)
• Most of trials was against root account
• A specific IP address tried with 4800 different passwords
• Some attackers tried with joe accounts
• admin/admin, guest/guest, ubuntu/ubuntu, oracle/oracle,
postgres/postgres, wordpress/wordpress, steam/steam etc.
• Passwords play an essential role of authentication scheme
• Developers/engineers should secure their authentication
• HTTPS, Log monitoring, Password hashing, IAM, Two-factor auth
• Users should use strong passwords and manage them properly
• Don’t use passwords like “hanako0630”
• Change default passwords
• Password strength - Wikipedia
• チョコっとプラスパスワード｜IPA 独立行政法人 情報処理推進機構
• Password Guidance - Microsoft Research
• Password guidance: simplifying your approach - GOV.UK