As seen on this answer https://stackoverflow.com/a/24929123/102957 the recommended method for authentication integration is to create users with a faux password (stored somewhere else or derived from the user data).
I find this authentication integration less robust than what I would like it to be.
When using this method:
will the password expire?
if the user, using some hacky technique, goes and changes the password, it will break completely, how can I restore the account password without knowing the previous password but having the quickblox account secret? Is this possible?
Password never expires
You can reset user's password by email http://quickblox.com/developers/Users#Reset_API_User_password_by_e-mail
Related
I'm making an parental application and I need the client (Windows Service) to update with the server every X seconds/minutes. For obvious reasons, I cannot have the user enter the password every time the client needs to update with the server, so I was wondering whether it would be better practice:
To send the username + password once, and get a token that doesn't expire until a new one is issued or
Store the username and password encrypted on the client computer
Using a token for authentication is always better that username+password because if someone manages to get access to the saved credentials (token or password) the damage by a revealed password is always higher that by a token that is random and is only used by your service and that can be replaced at any time.
Additionally humans tend to reuse passwords, which means a reveled password would raise security problems in more than just your service.
In my opinion OAuth2 is a good example of a token based authentication system: It has two types of tokens: refresh and access. The access token is like you have described and the refresh token allows to generate a new access token and invalidates the previous access token. This makes it possible to "update" the access token e.g. every week or month.
I know this might seem like a trivial question but I can't find the answer for it to at least put my mind at peace.
If a mobile app is communication with a server then typically they sign in and they get an access token that they can use for the remainder of the session with any future request.
WHY not just pass the user name and password over HTTPS with every request instead of the access token. An access token will need to be verified with database and so is the combination of username/password. Why go through the added effort of access token if they do the same thing? I know I am missing something but I can't figure it out
You are right in that an access token is verified pretty much the same way as a username and password. For the period when the access token is valid, it is pretty much equivalent to the username and password. In some cases (depending on your threat model) it may even be ok to send username and password with every request, maybe not from a mobile app, but for example in server to server requests, with appropriate controls.
However, you don't want to send the password in every request from a mobile app primarily because then you would have to store it.
The problem with a password (or with users, actually) is that they are reused. A password is a valuable target, because the same password is likely to be used on multiple services. So you exchange it for a shorter-lived access token, which, if stolen, presents less risk for your user. And you can't easily revoke a password - forcing users to change their passwords is a hassle. Revoking an acces stoken is easy.
Also it's very unlikely, but sometimes there are vulnerabilities in TLS - not very often, but there have been a few in the past years. Such a vulnerability might allow an attacker to decrypt some of the traffic sent over https, or for example there was a vulnerability in openssl a while ago that allowed attackers to extract parts of the server memory, potentially holding whatever the user(s) sent. It's much better if it's just an access token, and not the actual password.
Another point is sometimes (in OAuth flows) your app won't be allowed to even access the actual password. When your user logs in with a 3rd party identity provider (like for example facebook), they would not like your app to receive their facebook password. They just go to facebook, exchange their credentials for an access token, and you only see the token which you can verify with facebook if you want. But you never actually get the user's facebook password. Of course this is only valid when the identity provider is a third party.
I think the answer is all about the security and safety.
IT'S ALWAYS RECOMMENDED to use access tokens instead of username & password, because:
Access tokens (in most services) can be easily generated, blocked, monitored for their usage & statistics from your account, can be set as expirable, can have restricted permissions, and so on... Of course, you can delete it at all. The Username & Password is the master, who can control the access tokens.
Access tokens are safer as I said, and that is the most important thing. If you use Username & password in your web-application (or whatever) and that application is hacked (which happens so frequently), or someone views its source, or even some log-system saves the request parameters - then your user & password can be viewed by 3-rd parties and all your account can be hacked (and probably others too, where you have same user/pw). Access tokens eliminate all these risks.
About speed - I don't think that authorization with USER & PW has any significant advantage in speed.
I have IdentityServer4 setup for API authentication although I have a use case where I want to verify that a guest (user) is essentially a valid user. A valid user in my case is anyone with a valid email address, so I want to do the following:
send the user an email with a verification token (preferably something which is a mash up of their email address, some salt and an expiry
the user can then enter this token into my app and they are "allowed" to go ahead
I was wondering if IdentityServer4 can/should be used to achieve the above?
Their tools show that you can generate a token although I am very new to this topic so was hoping for some guidance.
No, the tokens Identity Server deals with are access_tokens which are to do with claims-based authentication.
The tokens you need to use for email verification are commonly referred to as User Tokens, or one-time passwords (OTP). You can find a wealth of information on how to generate/consume these using those search terms but if you use the aspnet identity classes such as the UserManager you will find it has some in-built read to use. Or you can register your own UserTokenProvider with the UserManager.
In general you'd do something like this:
Use your UserTokenProvider to get a token (otp) for a specific user. The UserManager will use the security hash of that user and your own 'reason' (e.g. "EmailVerification") to generate the short OTP.
You could then wrap that OTP into an object that includes the email address, a userid maybe, and whatever you like. Safe Base64 encode it (there is a helper function within Identity Server that has this in fact, making sure it doesn't have the superfluous _ at the end which will mess with HTML links), put it in an email to the user
User clicks your link which takes them to your 'verify password' controller, with your mashed up token as payload. You decode it, work out which user it was for, get UserManager to verify the OTP part is still valid.
Job done.
If you want them to enter the OTP into your app directly, while logged in, then you could just skip the whole mash-up part of emailing a link, and email the short OTP directly.
I am new to token based authentication and doing the following:
Authenticate the user by email and password,
get a token back from backend,
store the token in local storage,
check to see if a token is present. If yes then user is logged in.
What what I want to achieve is that if the user changes his password then the client should prompt for fresh login. How can this be done?
This depends whether you are using Refresh Tokens or not as user Gopinath Shiva describes in his answer to question about somewhat same domain.
If you use Refresh Tokens, then
When the user changes his password, change the refresh token of the user. Hence the remaining session will get logged out soon.
If you don't, then
When the user changes his password, note the change password time in the user db, so when the change password time is greater than the token creation time, then token is not valid. Hence the remaining session will get logged out soon.
I'm trying to set a cookie so that user can be automatically logged in.
I do not want to query DB for session string when authenticating cookies (basically I need to do that whenever most of my APIs are called, I want to make it faster)
the solution I found is to set a hash in the cookie and try to decrypt it when authenticating, if decryption is successful then log user in.
I am wondering what hashing method should I use? Do I just use a constant salt in my program and hash the userName with that salt, store the hashed userName and original userName in cookie, and try to match userName with decrypted hash upon authentication?
Since I am not familiar with hashing functions, can anyone kindly provide some suggestions on how should I do it in Java?
I recommend you to use an unique token key generated for each session. For example, if a client once logged in from a computer, this token will be valid until the password is changed. Expiring a cookie is not completely secure...
You can also use session variable for a simple authentication. Once you set a session variable for an user, every time this user sends a request with this session id; your session variable will be reached for just this session id. Most of the platforms can also use DB for storing these variables for you.
Two approaches:
1) Create your own authentication framework. In this case I recommend to put in a cookie an encrypted value of a username (I strongly not recommend to use hashing; also please do not put the user password value). For encryption please use AES-256 encryption with BouncyCastle:
256bit AES/CBC/PKCS5Padding with Bouncy Castle
If your framework success to decrypt the cookie – the user is authenticated. If your framework cannot decrypt the cookie or the user is not exist - the user is not authenticated.
2) Please consider to use the Spring Security framework:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
It is the great framework and solves a lot of authentication / authorization problems.
Your problem is solved by the “RememberMe” feature:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-remember-me
Best regards,
Michael
I don't come from Java background, but your hash key should never be something exposed.
For example:- In your case UserName is key and one of the fellow developers who knows what mechanism you are using can break it down because name is something very common and known.
Don't know what the best way is but I have used UserID(GUID) which is not visible in UI.