I am looking to implement a passwordless solution for a mobile app currently in production. The aim is to make the login process smoother for the users by removing the use of a password. Since the app is mobile only and that the phone number of the users is already used as a username I feel like a solution using Twilio to generate an OTP (one-time-password) to login is a good alternative.
Nonetheless today when a user logs in, the authentication token has no expiration date (he stay logged in forever). I would like to know if using an OTP to generate such unlimited (or very long lasting) auth token would be considered as a security issue. Is there some best practice to take into consideration like refresh tokens or other ...
To be clear my question is:
Is using OTP with SMS considered as a good practice to stay always logged in to an app ? And do you see any flaw in my reasoning ?
Thank you !
Look https://bere.al/en , Bereal use this system to auth users.
We have probleme when you change/lose you sim card.
But I don't see any security problem.
Related
I am developping a REST API with node.JS. I saw a lot of tutorials to secure my API, especially with JWT Library, but I think about an issue to this process :
I need to ask to my users to signup sending to my server an id and a password that I can store in my database to generate a token for the following actions. But what if a malicious user wanted to add a lot of user to my database by sending to the URI of my server a lot of time informations to sign up a lot of time ?
Is there a way to prevent an "attack" like this ?
Is Auth0 can help me ?
What you are looking for is something to limit or throttle requests made to your API endpoints. A good solution is to set up a middleware such as express-rate-limit.
I am running the open source parse-server and have well secured my database. However, my application requires administrator users which need to have the power to read and write nearly all the data. This is a security concern which I would like to address with two-factor authentication, though I am open to other ideas (IP whitelisting, cookies, or whatnot).
Setting this up on my client apps is straightforward enough and I have done that, but I would like to be even more secure so that if malicious agents have my Application ID (which is basically public) and somehow obtain an admin's credentials, they still cannot gain access.
I am puzzled as to how to accomplish this with the parse server as it is today. There are no Cloud Code triggers for User sign-in, so I can't enforce any MFA on the Parse server itself, as far as I can tell.
One possibility I see is to use check some MFA token in various Cloud Code routines, such as beforeSave, beforeDelete, and beforeFind, denying access to an admin user lacking proper MFA. Would that completely prevent a false admin from reading or writing all data?
The above option does not prevent the attacker from trying to brute force the MFA (assuming it's a 6-digit code). I also don't see any way of rate-limiting the login attempts of an attacker with the App ID and admin password. Any ideas here?
Thanks for any tips!
I really like the idea of adding 2FA and a small script to manage user accounts on the dashboard.
Can you open a feature request on https://github.com/parse-community/parse-dashboard ?
Also, for use authentication, you could probably use a custom auth adapter which would validate the username, email and 2FA token
There are quite a few examples and tutorials on authentication and node out there, as well as several questions on stackoverflow. I'm still struggeling with this subject however when trying to implement authentication for an API which communicates with a SPA. I tried using mean.js as an example as well as to use JWT and passport.js. But even after some days of research and trial and error it is still unclear to me how to achieve the following scenario:
A user registers himself with a username (or email) and a password (and gets an email to verify his account)
The user logs himself in with the password and username.
The user recieves a token as a response
The token is used in all following requests which require authentication (and is invalidated after a given amount of time).
If the user logs out, the token is invalidated and he gets a new one the next time he logs in.
At a later point of time I also would like to implement Facebook and Google Login (that's why I would like to use passport.js).
I'm glad for any help and also open to suggestions for a better authentication flow.
Looking into Firebase (https://www.firebase.com/). It simplifies the process of handling Auth and all the perils of trying to handle Auth yourself.
Firebase also supports all of the major Auth providers out of the box (Facebook, Google, Twitter, etc).
I ended up using the node-example of satellizer:
https://github.com/sahat/satellizer/blob/master/examples/server/node/server.js#L36
You store password and username to the database on signup.
For logging in one can you simply compare the (hashed) password with the proved one and send back a token you create via jwt.encode (jsonwebtoken).
After that you append the token to your requests (in the header is probably the best way) and check its validity via jwt.decode(token, TOKEN_SECRET)
Scenario: I have been developing a web application for management of small and medium-sized enterprises. Some time ago we used login and password authentication that were stored in our database. Nowadays when "everyone uses facebook" we moved to Facebook/Google OAuth2 authentication as well.
The problem is, there are some key operations that have to be especially secured (e.g. changing addresses, accessing clients' details). The best way to do this is I guess to ask users for retyping them credentials just before these risky operations are executed. But, since I use social authentication I can not confirm credentials anymore :(
Is there any way that I can force Facebook or other OAuth2 provider to re-ask users for credentials even they are already logged in?
I think this may be useful for someone.
I have found such a credentials confirmation implemented on https://www.airbnb.com but only for facebook.
AirBNB uses
https://www.facebook.com/login/reauth.php as an authentication url
Facebook re-authentication mechanism is described widely here:
https://developers.facebook.com/docs/facebook-login/reauthentication
For Google it is possible to force re-authentication by setting max_auth_age parameter to 0
No prompt for re-authentication with OAUth2. Why and how to force it?
I'm new to OAuth, and although I have scanned through many documents, I don't seem to have yet a good architecture / design to a secure web application, answering most/all of OWASP Top Ten
My newbie questions are
Why can't I just rely purely on OAuth? why do a user needs credential in my own application?
If I do, do I need hash / salt anything if I save it? I don't store any passwords, but what about tokens?
I still need to persist the users so they won't login everytime, (like in OS) - do I
Somehow use the OAuth token (save it? does it make even sense)?
Or use the plain old httpOnly secure cookie (if so, what happens if they log out of the Oauth provider? shouldn't I in this case ignore my cookie and let them log out?
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
I guess I have a lot to learn, but reading on so many potential security issues, and having to master so many different topics seems like a good potential for me missing something that someone later will exploit.
Is using a framework such as Spring Security, or using Lift's built in user management going to save me all this headache? or do I have to know exactly what I am doing to avoid things like Session Fixation, Cross Site Request Forgery, Cross site scripting, Rainbow tables and other things I only remotely get...
Why can't I just rely purely on OAuth?
From a service providers perspective, OAuth is a means of controlling access of third party applications to the business logic. The end user does not have to give out his password to the third party app, and the access can be controlled. For example, the provider could restrict the access to only parts of the service for limited amount of time.
If you write a third party application, there is no strict need for you to have your "own" user artifacts. You can rely on the users that authenticate your application.
You could require that user's have an account with a provider such as Facebook or Twitter and not implement any password stuff yourself.
(You probably need some sort of artifact to represent a user, it should in this case contain information about how that user authenticates your application, for instance an OAuth token, or an OpenID URL).
If I do, do I need hash / salt anything if I save it? I don't store
any passwords, but what about tokens?
Just to clarify, in OAuth a token is typically both a key and a secret, and they are needed in cleartext to sign requests (there are differences here depending on which version of OAuth you use). So you can store them encrypted, as long as it is reversible for you.
I still need to persist the users so they won't login everytime, (like in OS) - do I
somehow use the OAuth token (save it? does it make even sense)?
Yes this makes sense, a token represents your applications access to a specific user's data. Save the token if you want to keep a "session" alive.
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
There is no concept of "logging" out of OAUth, a token either has an expiration time or not. You can of course "log out" by simply choosing to forget the token. The next time you will have to redo the authentication. You cannot force users to invalidate an access token, unless the provider has an API for that.
You could save the token in a cookie, but I would use other unique identifiers for the session you want to keep alive. You can persist the details of the tokens server side. The information you store in your cookie shold make it possible to retrieve the token you need.
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
If you save a token in a database, save an ID for that token in a nice secure cookie. When a user goes to your service, use the information in the cookie to make a call from your service, to the service provider, to check if the token is still valid. If so, you have established enough trust for you to "log in" the user in your application without having to go through the pain of the OAuth process again.
And as a side not, StackOverflow uses OpenID and not OAuth for user authentication. OAuth can be used for the same purpose but is mainly a specification for application authorization.
I hope this helped, and don't sell yourself short. This site is for posting questions, not for appearing all-knowing.