
Bicycle Attacks: Quantifying the Damage of Widespread Password Length Leakage - adulau
https://arxiv.org/abs/2002.01513
======
unwind
Not being into security much (if I can help it) I had to look up the term [1].

Basically it's a reference to how a (tightly) wrapped bike is still
recognizable as being a bike.

[1]
[https://en.m.wikipedia.org/wiki/Bicycle_attack](https://en.m.wikipedia.org/wiki/Bicycle_attack)

------
dmurray
If you learn the exact length of a password, you gain say 3-4 bits of entropy?
4 bits if there are sixteen possible password lengths, all equally likely.

4 bits is not nothing, and it makes most cracking attacks 16 times easier, but
it's hopefully never going to be the difference between good security and bad.

~~~
tyingq
_" never going to be the difference between good security and bad."_

True, though there's plenty of bad out there.

Combined with dumb password rules, knowing the exact length could make things
pretty easy. Like the US Global Entry password rules:
[https://raw.githubusercontent.com/dumb-password-
rules/dumb-p...](https://raw.githubusercontent.com/dumb-password-rules/dumb-
password-rules/master/screenshots/global-entry.png)

8-12 chars with so many rules that already reduce the search space.

~~~
misnome
That looks saner than ours;

    
    
      The chosen password must:
    
      - Be at least 10 (ten) characters long (and must not be longer than 127 characters)
      - Contain at least 8 (eight) different characters, each of which is used only ONCE
      - Contain at least 2 letters (case sensitive)
      - Contain at least 2 numbers
      - Contain at least 2 of the symbols !”#$%&’()*+,-/:;<=>?@[\]^_`{}~¦
    
      The chosen password must not:
    
      - Contain a £ (Pound) character
      - Have 3 of any repeating character next to each other
      - Spell a word of 4 letters or more listed in a common dictionary (Most 4 letter combinations)
      - Be an abbreviation associated with the company
      - Be based on your user name
    

Unsurprisingly, almost everyone just memorises the initial random password
given out, since it's provided on a nice piece of paper when you start.
Thankfully there isn't also an expiry policy. The max length is large but
that's basically meaningless when you actually need to remember it and it
takes a while to come up with even a random password that fulfills these
requirements.

~~~
BrandoElFollito
I work in information security for 25 years. This is the most surrealistic
password policy I have seen.

Fantastic awareness training material you have here (in the section "see,
others have it worse than we do")

A sad part is that it is virtually impossible to use a password manager to
generate a new password.

------
tialaramex
It is surprising to me that modern browsers don't pad TLS (in TLS 1.3 padding
is "free" in the sense that you don't need any extra bytes to say "this is
padding") to fill the last packet.

Supposing MSS is 1500 for a link, how much longer can it conceivably take to
send say 1500 bytes including 120 bytes of padding versus 1380 bytes?

~~~
toast0
Software layering makes this much harder than it should be, but it's a good
concept.

One potential pitfall is that an unfortunate number of networks still have
poor path MTU detection, so padding that makes the packets larger than any
previously sent packet in the stream may result in a packet too large to
transit the network. Then you're at the mercy of ICMP delivery or path MTU
blackhole detection, which tends to be slow and isn't enabled on Android (!).

~~~
tialaramex
Somewhere, one of the layers is picking a packet size. Probably the OS TCP
stack. What I'd want to do as a TLS implementation concerned about hiding
exact lengths is use that packet length for my final packet regardless of how
much is actually inside it.

Yes if the MTU is bogus and causes fragmentation or dropped packets that's
bad, but I'm comfortable it also happened to every other packet sent, I'm only
making things go from terrible to slightly more terrible, not from good to
bad, and only for people who've got problems.

~~~
toast0
> Yes if the MTU is bogus and causes fragmentation or dropped packets that's
> bad, but I'm comfortable it also happened to every other packet sent, I'm
> only making things go from terrible to slightly more terrible, not from good
> to bad, and only for people who've got problems.

Certainly, this would only affect people who have problems, which is low, but
if you're always padding all requests up to the full MTU, it has the potential
to make things go from almost always working, to never working.

Looking at tcpdump with a real browser to one of my sites, firefox is only
sending pretty short packets, everything is less than 512 bytes. But if you
pad out to the full MTU, and the network is broken, those large packets may
all be dropped, and the ICMPs either supressed filtered or so rate limited
that they never get seen. Users on these networks with this padding would not
be able to make https requests to most servers, but would be able to make
connections to services where they have taken special effort to avoid MTU
problems.

Special efforts like: Google and Facebook clamp the maximum MSS they send to
1380 and 1400 for IPv4; FreeBSD used to return the client MSS in SYN+ACK if it
was smaller than the locally configured MSS, but that was removed with this
commit:
[https://github.com/freebsd/freebsd/commit/e1f9aeedee0bae9281...](https://github.com/freebsd/freebsd/commit/e1f9aeedee0bae92811248f9fcefa92ccb7be91f#diff-f3fd9f911dd76ffd9fbd0c8bfb458a61)

------
tyingq
It feels like browsers could fix this in a fairly simple way. Something like
using a value for the form boundary that varies in length for each request, or
a X-RandPad type header that has some variable length data?

~~~
madacol
I think there should be a protocol in browsers where input password fields are
hashed along with a blinding factor that comes from servers.

I think that protocol would solve lots of basic problems in password security.
But the most important thing is that it would serve as a proof that the server
is not saving your password in plain text, because the plain text never gets
there, only it's hash.

~~~
MattPalmer1086
I can't see how this would work. Does the blinding factor change every time
you log in? How does the server validate that your password is correct - what
does it store?

Server -> User : blinding factor

User -> Server: H(password || blinding factor)

Server: stores/checks what?

~~~
usrusr

      Server stores H(pw || bFixed)
      Server sends bFixed, bOnce
      Client sends H(H(pw || bFixed) || bOnce)
    

The server can be trusted to not save the actual password if setup/change is
already sending H(pw || bFixed) instead of the password itself. But then
bFixed becomes public knowledge knowledge and a leaked H(pw || bFixed) would
be enough to do a malicious login.

~~~
madacol
That's Interesting!. I didn't thought it that way

What I had in mind is this:

    
    
      Server stores H(H(pw || bFixedPub) || bFixedPriv) , bFixedPub , bFixedPriv
      Server sends bFixedPub
      Client sends H(pw || bFixedPub)
    

bFixedPub and bFixedPriv are unique per password.

------
rahuldottech
Shouldn't you be able to avoid this by simply hashing the password before
POSTing it?

~~~
cestith
If you're using JS to prehash before submission, an attacker who has
exfiltrated hashes never needs to crack them. It also makes it impossible to
degrade gracefully for a non-JS client. You're effectively taking a password
hash and turning it into an unhashed password itself.

------
blattimwind
Bicycle attacks, because remembering that biclique attack is not spelled
bicycle attack wasn't quite hard enough yet :-)

~~~
SAI_Peregrinus
"Biclique" is pronounced "bye-kleek". I don't think "bicycle" usually sounds
anything like that, so it shouldn't be too difficult.

