5 ms·

User name and password plus hardware token. Currently only U2F meets the requirements (supported in Chrome and Firefox with an extension) but soon enough Web Au

by hdhzy 10y ago

User name and password plus hardware token. Currently only U2F meets the requirements (supported in Chrome and Firefox with an extension) but soon enough Web Authentication [0] (successor of U2F) will be natively supported by all major browsers. The benefit of this approach is that you don't need complex passwords (4 digit pin will suffice) as the hardware token provides strong security. For bearer tokens use secure, httponly cookies that have names starting with __Secure- [1]. Check Origin header to protect against CSRF. Optionally consider using token binding [2] so that cookies cannot be exported at all. [0]: https://www.chromestatus.com/feature/5669923372138496 https://www.chromestatus.com/feature/5669923372138496 [1]: https://www.chromestatus.com/feature/4952188392570880 https://www.chromestatus.com/feature/4952188392570880 [2]: https://www.chromestatus.com/feature/5097603234529280 https://www.chromestatus.com/feature/5097603234529280

danieka 10y ago
That's actually quite cool. The use case in the spec indicates a really smooth user experience while providing great security. https://www.w3.org/TR/webauthn/#use-cases https://www.w3.org/TR/webauthn/#use-cases I'm definitely going to keep track of this standard, but as I understand it no browser has released it yet? Edit: I didn't properly read your reply, so disregard everything after "quite cool". :)
- hdhzy 10y ago
  Edge has Web Authentication support but only a draft version. The generated keypair is stored in TPM so after authentication credentials are basically bound to user's device. Web authentication is indeed quite cool. You can also drop passwords altogether and just rely on the token and the username (caveat: someone knows your username and physically steals your token is a threat) or even drop usernames at all! As U2F tokens generate new keypair per origin you'd only need the token to authorize. Of course if someone steals it and tries to login to your site... It's like physical key.
stephenr 10y ago
I don't understand what benefit a __Secure prefix for cookie names has, that just setting the secure flag doesn't?
- runamok 10y ago
  From their links: This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter). From: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/ https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/ Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers. The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.
  - hdhzy 10y ago
    Yes, exactly. After setting a cookie server usually cannot check if it is secure or not but using this prefix on modern browsers guarantees to server that the cookie is certainly secure. Of course it works only in modern browsers but it's part of defense in depth.
  - stephenr 10y ago
    I would consider a browser that allows a cookie with a secure flag to be overwritten from a http page buggy, and thus the solution would be simply enforcing the secure flag in a same way. What legitimate use is there for overwriting a secure cookie with a non secure one?

by hdhzy 10y ago

danieka 10y ago

That's actually quite cool. The use case in the spec indicates a really smooth user experience while providing great security. https://www.w3.org/TR/webauthn/#use-cases https://www.w3.org/TR/webauthn/#use-cases I'm definitely going to keep track of this standard, but as I understand it no browser has released it yet? Edit: I didn't properly read your reply, so disregard everything after "quite cool". :)

hdhzy 10y ago
Edge has Web Authentication support but only a draft version. The generated keypair is stored in TPM so after authentication credentials are basically bound to user's device. Web authentication is indeed quite cool. You can also drop passwords altogether and just rely on the token and the username (caveat: someone knows your username and physically steals your token is a threat) or even drop usernames at all! As U2F tokens generate new keypair per origin you'd only need the token to authorize. Of course if someone steals it and tries to login to your site... It's like physical key.

stephenr 10y ago

I don't understand what benefit a __Secure prefix for cookie names has, that just setting the secure flag doesn't?

runamok 10y ago
From their links: This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter). From: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/ https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/ Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers. The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.
- hdhzy 10y ago
  Yes, exactly. After setting a cookie server usually cannot check if it is secure or not but using this prefix on modern browsers guarantees to server that the cookie is certainly secure. Of course it works only in modern browsers but it's part of defense in depth.
- stephenr 10y ago
  I would consider a browser that allows a cookie with a secure flag to be overwritten from a http page buggy, and thus the solution would be simply enforcing the secure flag in a same way. What legitimate use is there for overwriting a secure cookie with a non secure one?