So I have a restful API that is responsible for handling the licenses for my app, it records
User ID
User email
Username
license expiry date
Currently what happens is the user authenticate via a third party auth service (firebase) then the app takes the user ID from firebase auth response and get the license info without any authorization on the license API.
Essentially if you have a user ID you can get all the info mentioned above
My question: Is this a security flaw? or is this acceptable considering that it is very hard for a malicious user to obtain another user's ID and even if he obtains the ID the info is not really that useful
This is a data protection question, not a programming question and you watch it from the wrong perspective in the comments. Information security and data protection and totally different jobs with different mindset.
User ID - personal data
User email - personal data
Username - personal data
license expiry date - probably company secret
What do we protect here?
Some not that sensitive personal data like username and email, which can be guessed by checking the companies webpage or linkedin. The license expiry date is not that important I guess, maybe the company wants to keep it in secret, who knows, better to ask them. The user ID if it is used only here is not a big deal.
What happens when somebody gets the user ID?
They can watch the upper data 24/7 until you add proper authentication or change the User ID. It does not matter how they get it, let's assume they can. They can watch HTTP packets, or an employee sends it by accident to somebody, or they steal this part from the database or they get it from HTTP server logs when you throw out a faulty HDD, who cares?!
What would be the effect to your company?
If your customers don't care about it, then ok. If they would terminate the contract immediately and report the data protection incident to an authority, you will be sued, etc. then it is an issue...
What else can happen?
Do you have support? Can somebody use the User ID and the upper infos to trick your support into terminating the contract and sending back money to the bank account they give? If so then it is an issue either.
Risk assessment is about checking the probabilities, motivations, consequences, etc. of something like the upper and mitigate them if necessary with risk reducing protective measures. Such a thing can be for example encrypting and signing the User ID and the session expiration date before sending it to your API, if it is possible to send encrpyted signed JWT by FireBase.
If the only way to access the record is a randomly generated UUID, then it is reasonable to consider the UUID to be a "secret key" and knowing it the equivalent of an authentication token. The UIUD space is extremely sparse; they are not guessable any more than AES keys are guessable. So the data is as protected as the UUID. You of course should still use HTTPS to protect the URL in transit. I use these kinds of schemes regularly (where knowing the UUID or knowing the SHA of the data is the authentication).
Related
I am currently developing financial services as a personal project.
In order to strengthen security in the project, it is designed and implemented to process authentication at the gateway stage using AWS API Gateway.
I tried to log in using a mobile phone number and the received authentication number, and I don't think this is appropriate for Cognito and IAM identifiers, so I'm going to run the Node Auth Server that issues and verifies JWT tokens in AWS Lambda.
In the process, I tried to include an identifier such as user_id or uuid in the payload of the JWT token, but my colleague opposed it.
His opinion was that access token should only engage in authentication and that the token should not contain a user identifier.
I agreed with him to some extent, but if so, I wondered how to deliver the user identifier in an API such as "Comment Registration API".
Should we hand over the user identifier along with the access token to the client when login is successful?
in conclusion
Is it logically incorrect to include the user identifier in Access Token's Payload?
If the answer to the above question is yes, how should I deliver the user identifier when login is successful?
I wanted to hear the majority's opinion, so I posted it.
Thank you.
Typically you want enough information in the access token so that you can also do proper authorization about what the user/caller is allowed to do.
Typically, you separate authentication and authorization like the picture below shows:
So, to make an effective API, you do want to avoid having to lookup additional information to be able to determine if you are allowed to access some piece of data or not. So, I typically include the UserID and some other claims/roles in the token, so that I can smoothly let the user in inside the API.
However, adding personal information in the access token might have some GDPR issues, but sometimes it might be necessary to also add. But I don't see any issues adding information like UserId and roles in the token.
Yes it is logically correct and a normal thing to do. To see how to do it in a Node Auth Server, you can look at this: https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/
I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.
Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).
However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.
Is there any reason why other services are using a token?
Which one is better as a security perspective or is there a better way to do this?
I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.
Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:
What you know. This can be the combination of username and password, or some special token.
What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
What you are. This is for example your fingerprint or retina of the eye.
Where you are. This can be the IP address of the origin if it is applicable for your setup.
How you behave. What is your normal way of using the service.
etc.
Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.
How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?
What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?
My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.
In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.
NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.
I'd go for a solution that is easier to implement and manage.
IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)
Here is how my application should work:
Users can use some functionalities of my application if they have enough chips (token) which they can buy from another application, or they can be granted to them upon some event, whatever.
Users have an attribute associated with them called 'chip', which represents some number. This information should be represented as a claim, probably.
I want Keycloak to do this authorization for me - to check whether user can use the functionality or not. I've come across JavaScript-based policies. It's seems they are able to operate on informations in tokens - like user email etc, but this is not my case where token can contain obsolete information, i.e. when token was generated user had enough chips but since then he spent them.
Maybe token should be refreshed upon spending chips, but in that case, would it be updated with current informations bound to user? Or maybe authorization service can somehow access database during evaluation of a policy? Could this work or are there any elegant solutions to this use case?
Keycloak is not here to check if the user has enough money. Keycloak is here to say if the user is authenticated and if he has the roles for a certain application (admin, user...).
Checking if the user has enough money should be on server-side. For an incoming request, you have to check in the database if the user has enough chips to access the application and if he hasn't you return 403.
I want to make a simple REST web app, where the user interact with the objects through links in an email. The links have a token that can be used to authenticate a user without a username and password, like the ones that are usually used to reset a password.
What are the best practices for such a login-less, token-based authentication system?
I am by no means a security expert.. but some of the points which come to mind are -
Lifetime - The token should expire after a set period of time. Indefinite access using the token certainly doesn't make sense.
Replay attacks - The mechanism should prevent replay attacks.. which means the token should be valid for not only a set period of time, but also fixed number of calls.. Ideally exactly 1. If this number is not exactly 1, then it opens another can of worms..
Unless, its a feature :( For example, by design, the user is expected to share link with others, and anyone with the link should be able to access the resource in question.
Authorization - Granularity of the access granted by the token. Is it black and white.. or is the token also associated with a fixed set of rights. For example - token X was issued for Read-Only access, vs token Y was issued, for same resource with R/W access.
Administration - User / Admin should be able to see and verify any currently active and issued tokens, and associated information (permissions granted / affected resource etc), and explicitly revoke them, if necessary.
Secure Communication - You should consider security of the medium through which the url with token will be sent to the user. i.e. in your scenario, do the users receive emails over secure channel (TLS / SSL)? Should the email itself be protected with DRM?
Man in the Middle / Leaks - Similarly, even though you are providing the url in email, and the user is not logging on using user name and password over SSL, the resource should still be accessed using the url with token over SSL. This will prevent any capturing of the tokens from url, by a man in the middle. You would also need to be very careful about when the users browser may use this url in places you didn't expect..
I can vaguely recall reading about a popular site being affected by their urls being used as Refer Url, when displaying ads on their website.. which means, the advertisers site would probably get the url with the token as Refer.
Generation - Choice of algorithm to generate the token - May seem pretty obvious, but the token should be extremely obscure and near impossible to guess or brute force. The tokens should never be reused and the algorithm should avoid collisions.
Server Side Security - The tokens should probably be treated with same security as you would secure users id and password. If your user database gets hacked, hackers should not get the users passwords and other sensitive information.. Similarly, if your user / resource / token database gets hacked, despite the expiration on the tokens, hackers should not be able to access the resources as users for x hours.
Point is, when the tokens are stored on server side, they should themselves be secured / encrypted.
On the same lines.. just like its bad practice to log information like passwords in log file (specially plain text), You'd also have to consider any place these urls may get logged (plain text) on your server.. For example web server logs. If only super admins should have access to user's database, then they should also be the only ones to be able to see these token.. Not your web server admin and not any hackers parsing the log file after the hack.
Auditing - If there will be a need for auditing, you'd need some mechanism in place to prove that while the user didn't log on to the system, they are indeed the ones who performed the action / operation in question. Would you want to track the ip address and other information along with the request which would help such auditing?
Consent - Do your users even consent to the use of such alternate means of authentication and authorization? Should this be an optional / opt in feature?
EDIT: I found a link to the referrer url problem I was recalling. Although it was in context of user information.
I agree to 10 points of Vikas however from security perspective I have to tell you few points that you must be careful.
I will try to keep as simple as possible. And here I simplify the technical stuff to your special case.
Firstly tokens are used to prevent Cross Site Request Forgery attacks (XSRF). Keep that in your mind. If there is a web platfrom without unique tokens on the forms then any attacker can force the user to make malicious requests.
If you simply try to authenticate the user with a token, this is pretty wrong. Because there must be no simple authentication process and you can not rely on token.
Here is how the login system works in official security documentations, im writing as I remember:
Identification: you have to identify the user firstly, that is generally done with username. YOu will know that there is a user exist in your system.
Authentication: Let's say you have already identified that user A want to login. So you mast authenticate the user A with something that you know and user A know. We call it password simply :) You cannot by pass this step with plain text methods. Passwords are generally encrypted in your db and also through all communication with secure certicates, check ssl.
Authorization: okay you made the authentication somehow, the user has a right to get Authorization. Let's say if the admin type user is logged in, he has differen rigts and if the normal user is logged in then she has regular rights.
Session control: finally you have to control the session with a secure way. Here generally in web applciations people use access tokens for all requests to be sure that the authorized user is aware of the request. As a platform owner you are responsible to secure everything until the session ends. If you don't satisfy the users with your security, then probably your platf is not going to survive longer.
Tokens have different lifetime to expire and different access rights.
Now let's look at what facebok like companies do with mobile aplications. For the mobile app they generate a unique access token which is alway alive. One shortcoming here is, if any attacker steal the mobile token generally she can do anything in the account anytime :) Anyway here our point is how they verify the users with those tokens; firstly the token is unique for that device. (Actually not exactly unique or not dependent on hardware, because if you clearly steal the necessary files from the device then you can use it on another phone). So with this unique access token which is generated with users password at their initial login on mobile app, they can login always automatically with that. And this method is a little similar to what you want to do. However pay attention that they don't authenticate the users with links or email code.
Verification is not an authentication, don't forget that. By sending e-mail you can verify the users if the emailed code is unique and valid for only 30 sec or 1 minute. I hope you got the point.
Here I suggest you to check single sign on across multiple domains, which is really interesting.
Single Sign On across multiple domains
Let's say you are logged in to google.com and then you visit the youtube.com Opps the youtube is already logged in? Yea, cool right, but exist for long time. They can authenticate users accross domains which use different cookies with a little and secure trick. You will read on the link.
If your service is not really confidential and if you want to make your users happy with easy login system. Here is two of my solutions which I love :)
1-) Ask users their email address: just directly send 4-6 digit code as e-mail. Ask user the enter/click on that. There will be no password at all, only unique code on each login.
2-) Let's say you need to verify the user with a stronger way than email. Then mobile phone :) Here trick is; you will not send the verification code to user, but they will send what you tell them to you.
Ask to user to send a SMS with a unique CODE to XXXXXX your number :) Connect your mobile operator with your web service and check whether the code is sent to you by the user :)
There is always a trade-off between security and simplicity, and also with complexity. You have to find the balance.
Don't try to make it simple if your security is going away.
Don't try to make it complex if it'll seem more secure.
Hope those informationn help you.
Do web browsers have a unique ID that can be passed on to Perl scripts? (Like a unique serial - like products that you buy in the shop have for example)
For instance: If I install a web browser, can this web browser provide a unique identifying ID to a PHP or Perl script?
The reason I'm looking for something unique is to do the following:
I have a user database with user names and passwords.
The user names / passwords are encrypted and set as cookies to the web browsers of users so that users can log in and out into my web application. (Each web page loaded when logged-in looks at the cookies and grants access if the cookie user/pass is correct)
If a hacker manages to steal the encrypted user name and password cookie from a user he will be able to log in with that stolen encrypted details.
If the browsers of users all had unique IDs to pass on then I could record those IDs and match them each time a user uses his encrypted user/pass cookie. This way if the unique ID does not match (what has been recorded previously) then the user is logged out and asked to manually log in again.
In the event where the encrypted user/pass is stolen the hacker won't be able to get in with it because unique browser ID's won't match. The user/pass cookie is encrypted and the hacker cannot see the user name or password. When the unique browser recorded ID's don't match the web application will ask the user to login manually and the hacker won't be able to login manually because the user/pass he stole is encrypted.
Using IP addresses is a possible solution but a poor solution because many if not most ISP's assign dynamic IPs to the internet connections of their clients.
Using time is also not a good solution because I would like the users to stay logged in on the same computer for weeks at a time (if they chose so) to make it convenient.
Anybody have any solutions to the above scenario?
I've been searching for a way to get something unique from browsers but this does not seem possible. Is it possible or not?
Browsers do not have a unique ID, but a good level of fingerprinting is possible. The EFF has measured that, in the best case, information sent by browsers (including the user agent string and other HTTP headers) represent 18.1 bits of entropy, which means if you take two browsers at random, you have 1 chance in 218.1 (≈280,000) that they will have the same "fingerprints". They have set up a website where you can estimate the degree entropy of the information sent by your browser.
Some websites use this. My bank, for instance, stores information about the three browsers I use most often to connect to their website, and ask me additional verification questions whenever I'm not using one of those.
On the other hand, all this information is entirely spoofable: if someone is able to carry a man-in-the-middle attack and steal a cookie, they are able to steal also all the headers sent by the browser, and can reuse them to authenticate themselves on your website. The same would be true if browsers actually had unique IDs.
Your alternative, besides using a connection encrypted with SSL (https) which requires you to either pay for a signed certificate or create a self-signed one that will display a security warning to your visitors, is to adopt better practice against session highjacking.
For one thing, it is not standard to keep the username and password, even if encrypted, in the cookie. What you should do is, once a user has logged into your website, assign them a random, single use session ID which you will store in your database along with an expiration time (which you may extend every time the user interacts with your website), and this to them in a cookie.
If you want an even higher degree of protection, one option is to change the session ID every time the user sends an HTTP request. You could also store a list of IP addresses each user uses to connect to your website, or IP address masks (e.g. X.Y.*.*) if it changes too often, and have them authenticate themselves if they are connecting from an unusual place. If you do this, it is a good practice to ask them "Will you be connecting again from this place?"
No, browsers don't have a unique ID. There is no such thing. If there were such a thing, it would be an online advertising company's dream!
That said, if you're serving up your site via HTTPS, you can issue your clients with client-side X.509 certificates. These would be cryptographically signed by your organization, so fairly unforgeable. (Though obviously if somebody had access to your client's computer they could make a copy of it - the same would be true of any browser ID number though!) Once the certificate is installed, every time the browser makes an HTTPS request to your website, your website can ask for its certificate, and this can be used to verify the user's identify.
You can store some unique values (e.g.: user id) in the user browser using "Html Local Storage" permanently with no expiration date, and store the same values with info about the user agent in the db.
Then you pass the user agent info with the data in the local storage and match it with the ones in the database...
// store
localStorage.setItem("myValue", "123-abcd");
// retrieve
var myValue = localStorage.getItem("myValue");
I'm not sure how much secure is this approach to identify users, but the Html Local Storage supposed to be accessible for only pages from one origin (same domain and protocol).
There is also "HTML Session Storage" to store data in the users browser for only one session.
Even we can use localstorage, sessionstorage and also cookies as well to implement this.. but wen these data s visble to user, so better to keep this encrypted