5 ms·

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy and security reasons. Or is this for use in URL-passed data (like email links?) If so, is this better than including a token as a key to a one-time, limited-time activity stored on the server?

meowface 12y ago
MAC schemes like JWT provide message integrity and a form of authentication that can't always be provided by TLS/HTTPS. The simplest way of describing it is that with HTTPS, when sending data to/from a server and a client (the client may even be another web server) you can be assured no one but the server or client can see or tamper with the data in transit. But the client is still able to trick the server, or vice versa, at the application level. To prevent that you need a message signing scheme (aka a MAC), and this is an example of one. For the case of password reset links from an email, generally speaking there's no point in using something like this; a one-time random token that you track and expire on the backend makes more sense. You'd only want to use a MAC if you need to freeze some kind of state in the URL and retain it, like perhaps a user's IP address. Then you can verify that the user's real IP address does indeed match the IP address in the URL; they can't tamper with the URL to change the IP address if a MAC is used. I don't know why anyone would want such a feature for a password reset function, and you could also replicate that same behavior just by storing the IP on the backend as well (though while also perhaps making your application somewhat more complex in the process), but that would be one example of doing something like that in a secure manner while still letting the client keep track of the state instead of the server. One common use of tokens like this is to defer state retention to all your clients so your server can do less work per request and store less data. Simply verifying that the MAC for a message is valid in every request is a lot faster than making a database/data store query to return session info for every request.
- sk5t 12y ago
  A minor-ish clarification on terms: a MAC algorithm (e.g., hmac-sha1) should not be conflated with a digital signing algorithm (e.g., rsa-sha1), as the MAC requires knowing the secret in order to validate. MACs are fine for checking that data haven't been tampered with, but do not have the properties of an actual signature that you can verify without being able to reproduce.
  - meowface 12y ago
    Yep, absolutely. I said "a form of authentication" because it allows some degree of message authentication, but not to the same degree a proper digital signing mechanism that utilizes public key cryptography would. The term "signing" is also kind of overloaded, and doesn't necessarily mean signing in the sense of a human signature. HMAC-SHA1 and RSA-SHA1 (or PGP) both can be said to "sign" a message, but they mean different things. Generally for web app development, I think MACs tend to suffice for the vast majority of use cases.
- muffy199 12y ago
  JWT only signs the token itself not the body of the request, so message integrity is still an issue without TLS/HTTPS
chrisrhoden 12y ago
You should still use HTTPS with this. The signing used here is not to protect the payload, but to ensure that an authority that you trust has issued the token.
easel 12y ago
The advantage is particularly that you don't have to use basic auth. Basic auth in a browser context is more or less a non-starter. The browser's basic auth implementation will take over and provide a generally poor, uncontrollable user experience. For server-to-server authentication, there is less to recommend this, although it does allow services to authenticate without having to check a credential against a data store someplace.
- jimktrains2 12y ago
  Which is sad, otherwise things like SRP could have become built in as well. I guess you could could kludge it into a form with a method="SRP" and have the browser do it's thing with the username and password field.
akbar501 12y ago
If you have a payload that does not require encryption, but does require authentication, then Hawk (from WalMart) is an option. https://github.com/hapijs/hapi-auth-hawk https://github.com/hapijs/hapi-auth-hawk https://github.com/hueniverse/hawk https://github.com/hueniverse/hawk Supported langs: https://github.com/hueniverse/hawk/issues?q=is%3Aclosed+label%3Aport https://github.com/hueniverse/hawk/issues?q=is%3Aclosed+labe...

meowface 12y ago

MAC schemes like JWT provide message integrity and a form of authentication that can't always be provided by TLS/HTTPS. The simplest way of describing it is that with HTTPS, when sending data to/from a server and a client (the client may even be another web server) you can be assured no one but the server or client can see or tamper with the data in transit. But the client is still able to trick the server, or vice versa, at the application level. To prevent that you need a message signing scheme (aka a MAC), and this is an example of one. For the case of password reset links from an email, generally speaking there's no point in using something like this; a one-time random token that you track and expire on the backend makes more sense. You'd only want to use a MAC if you need to freeze some kind of state in the URL and retain it, like perhaps a user's IP address. Then you can verify that the user's real IP address does indeed match the IP address in the URL; they can't tamper with the URL to change the IP address if a MAC is used. I don't know why anyone would want such a feature for a password reset function, and you could also replicate that same behavior just by storing the IP on the backend as well (though while also perhaps making your application somewhat more complex in the process), but that would be one example of doing something like that in a secure manner while still letting the client keep track of the state instead of the server. One common use of tokens like this is to defer state retention to all your clients so your server can do less work per request and store less data. Simply verifying that the MAC for a message is valid in every request is a lot faster than making a database/data store query to return session info for every request.

sk5t 12y ago
A minor-ish clarification on terms: a MAC algorithm (e.g., hmac-sha1) should not be conflated with a digital signing algorithm (e.g., rsa-sha1), as the MAC requires knowing the secret in order to validate. MACs are fine for checking that data haven't been tampered with, but do not have the properties of an actual signature that you can verify without being able to reproduce.
- meowface 12y ago
  Yep, absolutely. I said "a form of authentication" because it allows some degree of message authentication, but not to the same degree a proper digital signing mechanism that utilizes public key cryptography would. The term "signing" is also kind of overloaded, and doesn't necessarily mean signing in the sense of a human signature. HMAC-SHA1 and RSA-SHA1 (or PGP) both can be said to "sign" a message, but they mean different things. Generally for web app development, I think MACs tend to suffice for the vast majority of use cases.
muffy199 12y ago
JWT only signs the token itself not the body of the request, so message integrity is still an issue without TLS/HTTPS

chrisrhoden 12y ago

You should still use HTTPS with this. The signing used here is not to protect the payload, but to ensure that an authority that you trust has issued the token.

easel 12y ago

The advantage is particularly that you don't have to use basic auth. Basic auth in a browser context is more or less a non-starter. The browser's basic auth implementation will take over and provide a generally poor, uncontrollable user experience. For server-to-server authentication, there is less to recommend this, although it does allow services to authenticate without having to check a credential against a data store someplace.

jimktrains2 12y ago
Which is sad, otherwise things like SRP could have become built in as well. I guess you could could kludge it into a form with a method="SRP" and have the browser do it's thing with the username and password field.

akbar501 12y ago

If you have a payload that does not require encryption, but does require authentication, then Hawk (from WalMart) is an option. https://github.com/hapijs/hapi-auth-hawk https://github.com/hapijs/hapi-auth-hawk https://github.com/hueniverse/hawk https://github.com/hueniverse/hawk Supported langs: https://github.com/hueniverse/hawk/issues?q=is%3Aclosed+label%3Aport https://github.com/hueniverse/hawk/issues?q=is%3Aclosed+labe...