francois at mozilla.com
Sat Aug 23 10:34:40 PDT 2014
A few weeks ago I attended PasswordsCon with Brian. Overall, it was a
very good conference. I was particularly impressed with the program.
The highlights for me were:
* sqlcipher.net: transparent AES encryption for SQLite DBs with optional
support for Yubikeys
* a summary of CMU's recent research on password usability
* EFF's STARTTLS-everywhere postfix plugin
My full notes are attached, for those interested in the details. If
anything is unclear, feel free to ask, I might even remember what I
meant to write down:)
-------------- next part --------------
# Secure your email, secure your password
Why do it?
Try running this on public wi-fi:
ngrep -i password tcp port 25
There are two options:
1. end-to-end (involves users)
2. server-to-server (not as good)
RFC 3207 (starttls extension) describes opportunistic encryption for SMTP.
Only 13% of mail servers globally have starttls enabled with many of those
using self-signed or expired certs.
<http://starttls.info> is an online testing tool like `ssllabs.com`
EFF and ACLU will make starttls safer with their starttls-everywhere
Note: if you connect to your mailserver over 587, that requires TLS, it's
not opportunistic, it's mandatory.
# EFF's starttls everywhere
SMTP is mostly insecure.
STARTTLS is the solution against passive attacks w/o key theft. Perfect
forward secrecy is needed to defeat passive attacks with stolen keys.
On the web, we have HSTS for active attacks like MITM. For SMTP, the EFF is
It's a combination of HTTPS everywhere (for the first visit) and HSTS and it
also happen to work around the fact that MX records in DNS are not secure.
The current implementation modifies the Postfix config file and the hope is
to get it packaged for Debian so that it's just an apt-get away.
This line should always be in your postfix configuration:
smtp_tls_security_level = may
# CMU's work on secure and usable passwords
"guessability" is their way of measuring password quality. It measures
how many guesses are needed for a given password-cracking algorithm.
To measure usability, they count the number of incorrect attempts and also
use subjective metrics (e.g. asking users if it's hard to remember).
Password leaks are useful to quantify password guessability, but they don't
give any indication with respect to usability.
The Gawker and Startfor leaks were more guessable because the leak was of
hashed passwords and so only the cracked ones got out. Other leaks were in
plain text and the guessability of those is therefore much lower.
## 25K real-life passwords
They ran an experiment at CMU on real plain text passwords for their 25K
users (staff and students at CMU).
The RockYou leak had about the same guessability as the CMU passwords.
Age and role don't correlate with guessability, but department really
was. The Business school had the weakest passwords and the CS department had
## Password policies
Basic 16 passwords (16 chars, no other restrictions) are 5 times harder to
crack than basic 8 chars but comprehensive 8 (8 chars, all 4 char classes --
lower, upper, digit, symbol) is better than basic 8 for security.
Looking at 12 and 16 character passwords with one of:
* 2-word (contains two words)
* 3-classes (contains three of upper, lower, digit, symbol)
They found that these are best for security:
* 3-class 12
* 2-word 16
* 3-class 16
but that 3-class 16 is too hard to create.
They recommend one of:
* 3-class 12 (a little easier to create)
* 2-word 16 (better security)
## Password strength meters
All meters, no matter how silly, help users create better passwords.
Stringency of scoring algorithm matters a lot (but being too strict can lead
users to give up).
# Cryptanalysis of password hashing schemes
Problem: server hashing is done on CPUs but cracking is done on GPUs, FPGAs
and ASICs (Application-Specific Integrated Chips).
* Intel CPU = 2^17 hashes / joule
* AMD GPU = 2^22
* FPGA = 2^25
* ASIC = 2^32
Answer: use hash functions that take similar times on all hardware
Memory-hard functions were invented in the 1970s and that's what the PHC
(Password Hashing Competition) is about.
scrypt has problems:
* too many parameters and sub-functions
* allows trivial memory x time trade-off (i.e. if you have 1/4 the memory,
it takes 4 times longer)
* Reducing memory by 1/4 involves a penalty of q^l by design (where l is the
number of *permutation layers*), however, a new attack brough it down to 4q
* Decreased memory leads to insanely big penalties.
* The setup phase has small penalties but in the wandering phase, the
penalties increase much faster.
* Not as good as Argon but much better than Catena.
Note: data-independent transformations prevent cache timing attacks but can
# Cryptanalysis to speed-up cracking
Hash functions have these requirements:
* efficient to compute
* collision resistant (finding two inputs that hash to the same thing)
* second pre-image resistant (find a second plaintext that hashes to a given
* pre-image resistant (find the input that generated the hash)
| | | |
MD5 SHA HAVAL RIPEMD
| | |
SHA-1 RIPEMD-128 RIPEMD-160
| | | |
SHA-224 SHA-256 SHA-384 SHA-512
There are practical collision attacks on all 1st and 2nd generation MD4
(MD4, MD5, SHA, HAVAL and RIPEMD) but inversion (pre-image) attacks are much
MITM (**meet**-in-the-middle) attacks have become quite popular in
# Password expiration
After stealing a password, it's not always possible to install a backdoor,
so expiring a password does make sense. It allows you to mitigate against
undetected (succesful) attacks.
Also, in environments where passwords are shared, it makes a lot of sense to
expire them in order to ensure that staff lose access at some point after
There are generally two goals behind password expiration policies:
1. replacing a password before it's likely to be compromised
2. making sure that a new password is not related to the old one
These controls usually come with password expiration policies:
- password history (to prevent reuse of old passwords)
- min age before a change (to prevent overflow of password history)
- change notification (to let people know their password is expiring soon)
## Ideal password lifetime
Different organizations have very different guidelines:
* DoD Password Management guide says that passswords should never last longer
than 1 year to protect against unknown threats.
* Microsoft recommends changing passwords every 42 days in the Win2000 domain
* PCI says 90 days for non-consumer systems.
* SANS says 90 days too.
How often does password expiration thwarts an attacker using it? Don't know,
there's not much data available.
## User behavior
People who are told that their password has been compromised are very likely
to change it if they use the site regularly.
38% of users would rather do household chores than pick a new
password. Another 38% says that not forcing password changes is a sign of
bad security practices.
When forced to add numbers to a password, a lot of people will choose:
- 0 or 1
- the month of the password change (e.g. 10 for October)
- the year (e.g. 14 for 2014)
## Current trend
The current trend is to extend the duration of passwords or remove
Alternative to scheduled expirations:
- forced changes only when password is compromised or the policy changes
- intrusion prevention and behavioral profiling
- better feedback to users on suspicious activity in their account
- not user passwords as primary authenticator
# User auth on the web
Google Authenticator (in 2011) likely led to the mass adoption of TOTP.
Facebook has 2FA (SMS + TOTP) since 2011 too.
Almost all 2FA adoption is from self-enrolment.
Most services use SMS or TOTP. Almost all token-based systems are on banking or
"Two factor auth" is the most popular way to refer to that feature (MFA and
2-step auth are losing ground).
HSTS adoption by sector (overall 38%):
- technology: 40%
- financial: 33%
- gaming: 17%
- retail: 50%
- social: 50%
CSP adoption by sector (overall 7%):
- technology: 10%
- financial: 8%
- gaming: 0%
- retail: 0%
- social: 17%
Out of 141 sites that do 2FA, only 4 had all security features he looked
12 more had everything except CSP.
Only 2 (lastpass and github) of the 141 have all of the features and an A+
rating on SSLLabs.
SSLTrust is a CA and they only got a C rating on SSLLabs.
Only 3 of the 2FA providers have *reasonable* scores (Authy, Duo, LaunchKey).
Some sites have `x-hacker` or `x-hackers` for recruiting purposes.
<http://twofactorauth.org> has instructions for how to enable 2FA on many
# Auth in the cloud
When using OTP (e.g. TOTP), the secrets are in plain text on the server
instead of being hashed as is the case with passwords.
<http://s-crib.com> is building a very fast pay-as-you-go HSM for the
cloud. It's built out of smartcards.
# Offline brute-force attack on WPS
WPS gives you the access point's wifi passphrase in cleartext if you can
connect after pushing a physical button on the device or entering an 8-digit
PIN (1 digit is a checksum) that's printed on it.
In 2011, there was an online attack to brute-force the PIN in a couple of
hours. Newer devices will lock you out temporarily after 3 failed attempts.
Due to a bad PRNG in a very common consumer router, we can brute-force the
initial state and get the keys that the access point used to encrypt the PIN
hash. Then you get to brute-force the PIN and use the PIN to redo the WPS
dance and receive the passphrase in your 2nd attempt.
Another equally well-known consumer router use NULL keys.
Linux / hostapd looks OK since it uses `/dev/random`
# Proof-of-work as second factor
Key stretching protects against offline brute-forcing of passwords but
enables DoSing of the server.
Rate-limiting can be worked-around by attacking multiple targets at once.
The solution proposed here is similar to what hashcash did for email and
wordpress comments: brute-forcing costs the attacker CPU time.
The work: finding a partial collision in a given hash function (i.e. find a
number such that the hash of the provided nonce will have a number of
The difficulty is scaled (could be linear or exponential) based on:
- IP addresses
- failed attempts
- profile (e.g. country of origin)
- server load
Server-side in PHP, client in JS.
Proof verification is fast (but nonce generation is a bottleneck) so it
should be done before considering other factors.
Client-side JS speed depends a lot on the JS engine. The average compute
time is OK but the outliers are a problem:
- Below 10 collision bits, it's too fast to be useful.
- iPhone4 is way slower than everything else.
They recommend a value between 11 bits and 18 bits to avoid a runtime of >
24 s on slow iPhones).
- precompute all possible proofs (the nonce is 128 bits though so it's not
- don't use the provided JS code and instead write your own GPU-based code
- pick your own nonce and number of bits and submit that as a proof of work
To fix the third attack, they store a signed cookie with that the nonce and
number of bits in it (similar to client-sessions cookies). However, you
still need a (bounded) replay table to prevent clients from reusing previous
proofs-of-work before they expire (we designed this in the token server).
Ran a 1000-people user survey which found that:
* 70% of people reuse passwords
* > 50% only change their passwords slightly when they have to
uSig is a mobile-only login system designed to become part of the NASCAR.
To login with uSig, you select a photo from the picker on your phone. uSig
hashes your photo and sends that to the server.
Because the photo never leaves the device, you'd have to somehow transfer it
to another device to log into the same account with two devices.
# Hash delegation
Server relief protocol:
client --------id--------> server
client <----user salt----- server
client --hash(pw, salt)--> server
The server stores hash'(hash(pw, salt)) where hash is the slow hash function
and hash' is a fast one.
Hashing delegation: enlisting other computers into the "server's army" to
tilt the password hashing game in the favor of the defender.
A PHC canditate based on RSA keys that are Blum integers (n=pq) and uses
The hard work is repeatedly squaring the number modulo n.
Fast path: if you know p & q, you can do the squarings faster, but that's
* can be delegated
* allows the hashed password and an escrowed password as a single value
* increase the work factor offline w/o requiring clients to do anything
Makwa is currently quite competitive in terms of performance/cost given the
types of hardware available, despite its CPU-only cost (i.e. not memory
hard). This may not last however.
# Net authentication
POP3 uses plaintext passwords sent over the wire to the server, while APOP
is challenge-response. However, you can pretend that the challenge is a salt
value and run this in a regular password cracker.
This challenge-response protocol works like this:
1. server sends client a string
2. client hashes it with password and sends it back to server
3. server verifies the hash by computing it too with its copy of the user's
The server only needs a hashed password from the user to do the
Simple Auth Security Layer allows crypto APIs to be plugged in and is
supported by a lot of Internet protocols.
GSSAPI is there to bridge Kerberos with SASL.
The basic authentication flow works like this:
1. client sends username to server
2. server sends a message back encrypted with the hash of the user's password
3. client extracts "things" from the message after decrypting it
Kerberos supports lots of plugins to hash the password and encrypt the
## Dynamic DNS services
Microsoft hijacked the NO-IP dynamic DNS service because it was used by
There is a way in the DNS protocol to update your IP address securely. DNS
TSIGs have a pluggable authentication system.
However, NO-IP used plaintext password sent over HTTP.
## Bitcoin miners
The miners usually send their username/password in clear text but that's OK
because it's just for the workers and the main account has different
The Session Initiation Protocol only starts phone calls (RTP carries the
actual conversation) but it sends your username/password in cleartext over
the wire every few minutes as part of registering with the server to receive
## HTTP Auth headers
* Digest-MD5 is very crackable and looks like CHAP.
* GSSAPI is also available in Chrome, Firefox and IE.
Because BGP doesn't support auth at all in the protocol, a new TCP option
(MD5) was added and is pretty much only used for BGP.
# Passwords for all reasons
*by jeff at agilebits.com*
Security properties of auth keys v. decryption keys are quite different. A
*key* is only a good metaphor for authentication.
Authentication: a prover demonstrates to a verifier that they are who they
claim to be.
[[!table class="border" data="""
| Encryption | Authentication
password change | lose data | OK
password revocation | no | OK
recovery / reset | no | OK
forward secrecy | sometimes | OK
Is the key capturable?
[[!table class="border" data="""
| Encryption | Authentication
in transit | rarely transmitted | yes
from client/server | yes | yes
from verifier/server | no | possibly
What are the possible defenses?
[[!table class="border" data="""
| Encryption | Authentication
slowing attacks | costly key derivation | throttling / locking
splitting secrets | key splitting | multi-factor auth
changing secrets | - | one-time password
If someone steals your password-protected GPG secret key, changing the
password doesn't do anything. Once you publish an encrypted file, you can
never take it back so the key becomes very precious.
"Biometrics: everything that's wrong with passwords, plus you can't change
# Enhancing password-based key derivation
[SQLcipher](http://sqlcipher.net) is a FOSS extension to SQLite that provides fully transparent AES
The whole file is encrypted based on your password stretched using PBKDF2,
using a unique per-database salt.
The DB file structure looks like this:
| salt | encrypted data |
| encrypted data | IV | MAC |
| encrypted data |
| encrypted data | IV | MAC |
## Adaptive work factor
They don't use a static key derivation work factor. Instead they use an
**adaptive KDF work factor** which computes the work factor based on
It runs automatically and is constrained by a configurable number of
The work factor is stored in a new experimental header.
## Second factor in key derivation
In order to add an additional factor to the key derivation process, they use
a hardware device (Yubikey or [daplug.io](http://daplug.io)). Both of these
- programmable write-only keys
- on-board HMAC-SHA-1 challenge-reponse API
They send the DB salt to the token and essentially get a permutation of
it. Operating on the salt doesn't reveal anything secret to the hardware
* [MFA-related code](https://github.com/sqlcipher/sqlcipher/tree/vfs)
* [MFA-related tools](https://github.com/sqlcipher/sqlcipher-mfa)
More information about the Dev-fxacct