My current design is when the website server authenticates the user it generates the API authToken and injects along with the total initial state of the page and then the API requests are served with this authToken, is this flow inherently flawed? I thought of using an extra HTTP request after page loading to get the API authToken and thus avoid putting it inside the HTML body but that means more slowness since the page contents is usually dependent on the API requests which need an extra HTTP request after the page load to get the API authToken. I assume the connection is already over HTTPS of course.
I don’t know the theoretical background for 2FA so I’m asking here.
I’ve used a few 2FA apps before including Duo Mobile and Steam Mobile (Guard). When Duo is opened, it will display your tokens as you expect, but with Steam your Guard token is displayed wether you are logged in or not. The Guard behavior caught my attention because I was expecting to need to be logged in first to see the token, since the token is tied to my account unlike with Duo where services are registered for use. That being said, Duo could use a master password (a la LastPass) so further protect the tokens.
So my question is do the workings behind 2FA (mobile apps specifically) consider if a user should be authenticated on the 2FA app to get access to tokens?
My theory is the security level is the same as SMS 2FA, where you can assume only the real user can access tokens because they know the phone’s lock screen pin. In this system, the phone is the authenticator and exclusive access is granted by knowing the lock screen pin. But with 2FA apps, the app is the authenticator, but has no way to provide exclusive access. Anyone with access to the app (imagine a shared phone where 2+ people know the lock screen pin) can access the tokens.
I’m trying to secure a REST API that I’m using as a backend for a single-page application. The API provides access to read/create/modify/delete protected resources, based on a set of permissions managed by an administrator. What I’m thinking is the following:
- All connections must be over HTTPS; plain HTTP requests will be redirected to HTTPS.
- Users have a username and password, which they create.
- A client submits a username/password to a
/login route; if it’s a valid password for that user, the server will return a short-lived access token and a long-lived refresh token.
- The access token will be a signed JWT that identifies the user and has an expiration time.
- The refresh token will be a GUID corresponding to a row in a database table; this row will store the user ID
- When accessing protected routes (everything but
/login), an access token will be required. The server will verify the signature, and if valid, will check the expiration time. If the token is not expired, the user ID will be made available to server-side code for authorization logic.
- If the access token is expired, the client will automatically submit the refresh token to a
/refresh endpoint for requesting a new access token. The server will check the database; if a corresponding row still exists, a new access token will be returned to the client.
Does this scheme sound secure?
I have a system with an OAuth2 authorization server. It hands out JWT access tokens and refresh tokens (the latter only to the mobile app client).
We don’t persist access tokens (as is normal with JWT) but we do persist the (hashed) refresh tokens together with some meta data to be able to revoke them so that users can log out other devices. We also only allow a single use for refresh tokens, the new request also gives back a new refresh token.
The OAuth2 login server itself uses regular basic auth with sessions. The user wants to be able to logout (single devices/clients) here. So of course I have to invalidate the session itself. But ideally I want to remove the refresh token that this client still has as well. The problem is that I don’t know that refresh token. A particular user could in theory have request multiple of them with their code request. The refresh token is also not normally passed in requests (only the access token)
Should I ask the clients (which are currently all under our own development) to send along their unused refresh tokens? Even if they ‘forget’ their refresh tokens locally, it still seems better if I also delete them on the server so they don’t linger around until their expiry time. Note I do know all the refresh tokens currently in use for a certain account but I don’t want to just delete them all because that would mean all devices are logged out. We also save some user agent-like info with the refresh tokens so users can use that to manually logout other devices, but it seems like a bad idea to try to perform string matching on those to automate that process.
I have bought the Tails of Equestria starter set to play with my children. On page 5 of A Dragon’s Bounty the following things are stated:
- Each pony begins with 1 Friendship point
- You can spend 1, 2, or 3 friendship points for different effects
This begs 2 questions:
- How do ponies get more than 1 friendship point?
- What does spending mean? Do they just leave the game, or do you give them to another pony?
I wonder if this is explained in the full rules, which I don’t have.
Note: for people who only have the full rules, I should say that A Dragon’s Bounty is a GM-less, choose-your-own-adventure style affair.
The app requires that the user be prompted for some kind of identifying information whenever it is launched, but for ease of use this need not be their full username and password. Password entry in particular (and especially on mobile devices) will be too cumbersome to make this feasible. Therefore, we are considering a once-off login procedure where the full credentials are supplied, followed by a “setup” step where the user creates a PIN for future access. This could, in future, be extended to allow a fingerprint/face scan to also “unlock” the app on supported devices.
My initial thoughts on implementation are:
- The user submits a valid username/password combination to a
login/ endpoint of the API and receives an “ID token” in response.
- During the “setup” phase, the PIN chosen by the user is used to encrypt the ID token.
- The encrypted ID token is stored in
- A secondary request is made to an
authorise/ endpoint of the API, including the plaintext ID token. Assuming the token validates, a second token is issued to the app.
- This second token is what is used in all subsequent requests to the API to prove the user is trusted, has a relatively short expiry, and is not stored in any persistent manner by the application.
- Upon returning to the app at a later date, the user need only provide their chosen PIN.
- It can be used to decrypt the stored ID token, which is then used in the
authorise/ request to generate and return a new short-lived session token.
The internet abounds with articles advising against the use of
LocalStorage for anything sensitive, due to its exposure in the event of XSS attacks. The threat is that a token in
LocalStorage could be stolen when the same token in an httpOnly cookie could not. It is worth noting that in both cases, a malicious script running within the app could successfully issue fraudulent requests to the backend API.
I believe the XSS threat of the ID token being stolen is mitigated by it being encrypted under the user’s PIN, and neither the decrypted value nor the PIN itself being stored or used beyond the
I think the above sounds like a secure way to implement our requirements, but I am no security expert. Am I missing any obvious weaknesses here? Does this actually sound secure?
I want to figure out how safe is to implement a 15 bytes long password reset token.
If we have 26 letters and 10 numbers, 36 possibilities per byte. And we have a 15 byte long token, that means that the total amount of possibilities is 36^15.
Is it possible to brute-force and find a token in a reasonable amount of time? The amount of possibilities here is really really big, so i don’t understand why other websites implement a +32 or +50 byte long tokens.
Can someone explain that and maybe the math behind this to probe if this is possible?
Let’s assume we can brute-force at 15k request per second
I am trying to understand statelessness in restful APIs in the context of authentication. Here’s the scenario:
- The user logs in.
- The server verifies the username and the password, and generates an opaque access token. It caches some information related to this token – for example, the expiration time, the userId, whether this token was explicitly invalidated before it expired, etc.
- The token is sent to the client, and the client sends it with every future request.
Fielding’s dissertation defines statelessness as:
“…such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.”
In my example, the client is sending the token with every request, so the first condition is satisfied. However, my server has a context associated with this session that is stored in the sessions cache.
Does this make my application stateful?
If yes, then is it that true statelessness be achieved only if we are using JWTs? I am pondering upon this as JWTs are quite new, so how were architects building truly stateless services before they were invented?
I am selling services of 10,000 Tokens from Linkcollider.
Payment Method – Paypal
Chat on Skype : marl09
Bitwarden (as an example) allows you to store your TOTP tokens in it. That is: you can use the mobile app to scan the QR code that (e.g.) Amazon AWS gives you, and then it’ll generate TOTP codes.
So far, so exactly the same as Google Authenticator and similar.
Bitwarden synchronises your “vault” (to their servers by default; you can install your own server), including the TOTP … stuff. This means that your credentials (including TOTP codes) are available on all of your associated devices.
Is that a good thing, from a security point of view? It’s definitely convenient — I just got a new phone, and resetting all of my MFA tokens is … not a pleasant use of my time.