4 ms·

Hah, that page actually allows you to test whether or not a certain email address is signed up for the service, which seems like an even worse idea given what t

Hah, that page actually allows you to test whether or not a certain email address is signed up for the service, which seems like an even worse idea given what they're to become.

kazagistar 8y ago
How do you actually prevent this? It seems impossible to prevent that information from leaking via timing attack.
- dasil003 8y ago
  Requiring a timing attack and having throttling on any such endpoints raises the bar quite a bit by itself. As to preventing timing attacks you can add a delay to give a uniform response time.
  - CiPHPerCoder 8y ago
    > As to preventing timing attacks you can add a delay to give a uniform response time. You have to be very careful with how you implement the delay to prevent the timing signal from still propagating to the attacker. https://blog.ircmaxell.com/2014/11/its-all-about-time.html#A-Note-On-%E2%80%9CRandom-Delays%E2%80%9D https://blog.ircmaxell.com/2014/11/its-all-about-time.html#A...
- jedberg 8y ago
  Usually you do it by giving the same response for an invalid password and a non-existent email. I wanted to see how that particular page was leaking but the site wouldn’t load for me.
  - RcouF1uZ4gsC 8y ago
    That won’t really help in general because you can go try to sign up with an email address. It has to tell you if the address is already taken or not.
    - 0x6c6f6c 8y ago
      Absolutely. It's really more relevant with services you can't directly sign up for, such as an internal service in the company where user enumeration helps you find a target when the error messages are different.
    - insomniacity 8y ago
      Not quite - best practice is to continue the initial setup - ie, "we've sent you a link, please click to activate your account". Except if the email address is already in use, you email the address and let them know that. That way they only leak that info to the owner of the email address - and they can include a password reset link too.
      - MattSayar 8y ago
        How about for websites that give you some functionality without a verified email address? At that point, you can't let a user dink around if the address is in use. Granted, this doesn't apply to eg banks, but there's plenty of websites where this could apply.
        JimDabell 8y ago
        Don't ask for their email address then. What's the point in having an email address that you have no idea if it's correct or not? You might as well ask them to put in a random string of characters.
- kodablah 8y ago
  You should validate credentials all at the same time. In general, you only fail a login at the end of the process, not halfway through. Also every login failure, regardless of reason, should be accompanied by short, random server-side sleep before returning (e.g. random between a couple hundred milliseconds and a second).
  - menacingly 8y ago
    I still think that's vulnerable to timing attack. Timing attacks are the voodoo that should keep us up at night, a clever attacker can extract information that seems impossible.
    - xvector 8y ago
      With unlimited logins, it is indeed vulnerable to timing attacks. You could measure the mean time of a certain email against the mean time of another email. This effectively gets rid of the random delay. Perhaps you could measure the time of the login process and adjust the random delay based on how long the process has taken. If you can get this to average to a <1ms difference between the "email exists" and "email doesn't exist" you could probably defeat any timing attacks over the network. That, or just limit retries and have different random timeouts for every login. Now you can't try enough times to get a good estimate of the mean for each login path, and you can't use other logins to help you refine your estimate because each has different timeouts.
    - thaumaturgy 8y ago
      Once upon a time I thought this was a pretty serious avenue of attack and wrote login forms to always run on the server in constant time -- starting a timer at the beginning and only returning output after a fixed number of ms. I mostly don't bother anymore, because an effective timing attack for account discovery against something that's doing everything else correctly should take so many attempts that it should wake up whatever brute force protection sites should be running now anyway. Given the number of dumb automated brute force probes against just about anything with a login, you can't just allow an infinite number of requests from a single IP (or a handful of IPs).
paulddraper 8y ago
What the vulnerability? You find out that an email address belongs to a Swiss citizen?
- jstarfish 8y ago
  No, but given a list of random addresses of Swiss citizens scraped from wherever, you can validate each one by checking them against this portal. If it shows up, it's an active address.

Hah, that page actually allows you to test whether or not a certain email address is signed up for the service, which seems like an even worse idea given what they're to become.

kazagistar 8y ago

How do you actually prevent this? It seems impossible to prevent that information from leaking via timing attack.

dasil003 8y ago
Requiring a timing attack and having throttling on any such endpoints raises the bar quite a bit by itself. As to preventing timing attacks you can add a delay to give a uniform response time.
- CiPHPerCoder 8y ago
  > As to preventing timing attacks you can add a delay to give a uniform response time. You have to be very careful with how you implement the delay to prevent the timing signal from still propagating to the attacker. https://blog.ircmaxell.com/2014/11/its-all-about-time.html#A-Note-On-%E2%80%9CRandom-Delays%E2%80%9D https://blog.ircmaxell.com/2014/11/its-all-about-time.html#A...
jedberg 8y ago
Usually you do it by giving the same response for an invalid password and a non-existent email. I wanted to see how that particular page was leaking but the site wouldn’t load for me.
- RcouF1uZ4gsC 8y ago
  That won’t really help in general because you can go try to sign up with an email address. It has to tell you if the address is already taken or not.
  - 0x6c6f6c 8y ago
    Absolutely. It's really more relevant with services you can't directly sign up for, such as an internal service in the company where user enumeration helps you find a target when the error messages are different.
  - insomniacity 8y ago
    Not quite - best practice is to continue the initial setup - ie, "we've sent you a link, please click to activate your account". Except if the email address is already in use, you email the address and let them know that. That way they only leak that info to the owner of the email address - and they can include a password reset link too.
    - MattSayar 8y ago
      How about for websites that give you some functionality without a verified email address? At that point, you can't let a user dink around if the address is in use. Granted, this doesn't apply to eg banks, but there's plenty of websites where this could apply.
      - JimDabell 8y ago
        Don't ask for their email address then. What's the point in having an email address that you have no idea if it's correct or not? You might as well ask them to put in a random string of characters.
kodablah 8y ago
You should validate credentials all at the same time. In general, you only fail a login at the end of the process, not halfway through. Also every login failure, regardless of reason, should be accompanied by short, random server-side sleep before returning (e.g. random between a couple hundred milliseconds and a second).
- menacingly 8y ago
  I still think that's vulnerable to timing attack. Timing attacks are the voodoo that should keep us up at night, a clever attacker can extract information that seems impossible.
  - xvector 8y ago
    With unlimited logins, it is indeed vulnerable to timing attacks. You could measure the mean time of a certain email against the mean time of another email. This effectively gets rid of the random delay. Perhaps you could measure the time of the login process and adjust the random delay based on how long the process has taken. If you can get this to average to a <1ms difference between the "email exists" and "email doesn't exist" you could probably defeat any timing attacks over the network. That, or just limit retries and have different random timeouts for every login. Now you can't try enough times to get a good estimate of the mean for each login path, and you can't use other logins to help you refine your estimate because each has different timeouts.
  - thaumaturgy 8y ago
    Once upon a time I thought this was a pretty serious avenue of attack and wrote login forms to always run on the server in constant time -- starting a timer at the beginning and only returning output after a fixed number of ms. I mostly don't bother anymore, because an effective timing attack for account discovery against something that's doing everything else correctly should take so many attempts that it should wake up whatever brute force protection sites should be running now anyway. Given the number of dumb automated brute force probes against just about anything with a login, you can't just allow an infinite number of requests from a single IP (or a handful of IPs).

paulddraper 8y ago

What the vulnerability? You find out that an email address belongs to a Swiss citizen?

jstarfish 8y ago
No, but given a list of random addresses of Swiss citizens scraped from wherever, you can validate each one by checking them against this portal. If it shows up, it's an active address.