Authentication - sgtbelly/class-1 GitHub Wiki
Authentication
Security:
The BA mechanism provides no confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit, but not encrypted or hashed in any way. Therefore, Basic Authentication is typically used in conjunction with HTTPS to provide confidentiality. Because the BA field has to be sent in the header of each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers. Microsoft Internet Explorer by default caches them for 15 minutes.[1] HTTP does not provide a method for a web server to instruct the client to "log out" the user. However, there are a number of methods to clear cached credentials in certain web browsers. One of them is redirecting the user to a URL on the same domain containing credentials that are intentionally incorrect. However, this behavior is inconsistent between various browsers and browser versions.[2] Microsoft Internet Explorer offers a dedicated JavaScript method to clear cached credentials:[3]
<script>document.execCommand('ClearAuthenticationCache');</script>JWT
When should you use JSON Web Tokens?
Here are some scenarios where JSON Web Tokens are useful: • Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains. • Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
Authentication Cheat Sheet
TLS Client Authentication TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.
It is a good idea to do this when:
It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser. The user is not easily scared by the process of installing TLS certificates on his browser or there will be someone, probably from IT support, that will do this for the user. The website requires an extra step of security. It is also a good thing to use when the website is for an intranet of a company or organization. It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and TLS client authentication combined.
bcrypt Security Issues/Concerns Per bcrypt implementation, only the first 72 characters of a string are used. Any extra characters are ignored when matching passwords.
As should be the case with any security tool, this library should be scrutinized by anyone using it. If you find or suspect an issue with the code- please bring it to my attention and I'll spend some time trying to make sure that this tool is as secure as possible.
To make it easier for people using this tool to analyze what has been surveyed, here is a list of BCrypt related security issues/concerns as they've come up.
An issue with passwords was found with a version of the Blowfish algorithm developed for John the Ripper. This is not present in the OpenBSD version and is thus not a problem for this module.
jasonwebtoken jwt.sign(payload, secretOrPrivateKey, [options, callback]) (Asynchronous) If a callback is supplied, the callback is called with the err or the JWT. (Synchronous) Returns the JsonWebToken as string payload could be an object literal, buffer or string representing valid JSON.
jwt.verify(token, secretOrPublicKey, [options, callback]) (Asynchronous) If a callback is supplied, function acts asynchronously. The callback is called with the decoded payload if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will be called with the error. (Synchronous) If a callback is not supplied, function acts synchronously. Returns the payload decoded if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will throw the error. token is the JsonWebToken string jwt.decode(token [, options]) (Synchronous) Returns the decoded payload without verifying if the signature is valid. Warning: This will not verify whether the signature is valid. You should not use this for untrusted messages. You most likely want to use jwt.verify instead. token is the JsonWebToken string options: • json: force JSON.parse on the payload even if the header doesn't contain "typ":"JWT". • complete: return an object with the decoded payload and header.