I have developed simple website using Tomcat and Java. Now I'm trying to add authentication to it. I am storing username and encrypted password in database.
How do I validate user on every request to website?
While doing my research I found out that I need to set some cookie, return it to browser if user is authenticated, and then validate it request by checking this cookie in every request I get from user.
Also, how do I manage the session, i.e. create new session for user upon authentication, set timeout, clear session and cookie upon logout?
Web development and particularly authentication/user management is very new to me, so I will appreciate your help.
Thanks.
This will depend a lot upon the language you are using to develop the website and how you plan to handle sessions.
PHP Sessions
Java (JSP) Sessions
ASP.NET Sessions
ASP Sessions
...etc
the list goes on, especially with how to manage authenticating.
The general (pseudo code) for this usually revolves around something of this nature
Depending on the language of course:
User Creates Account (typically an HTML form posting to your server side code)
Account Information Is Stored to the database
Cookie is created with information allowing user to auth in the
future (with cookie duration)
Session is created for the duration of the users login
User leaves the website
User comes back to the website
Website checks for stored cookie
if Cookie is found - check cookie, is the auth still good? (did the
users password change recently? has the cookie expired)
If the cookie is good - create a new session and allow the user into the website
If the cookie is bad - present the user with a login form
Rinse/repeat as the user logs in and out.
Depending on your language you will want to look at different resources, however cookie generation is a pretty simple task and can be easily done with JavaScript and HTML. Take a look at http://www.w3schools.com/js/js_cookies.asp and see if it meets your needs. Note that from what I recall JavaScript only does Cookies, and not sessions.
Related
What are the security implications of storing a user's unique ID in a cookie?
Logging-in is managed separately. The presence or abscense of this cookie is simply used to determine:
Is this a returning user?
If so, who did this user last login as.
These are all merely hints, the user doesn't get any more rights (before login) than a first-time visitor to the site.
Background
My web app front-end is implemented in Angular4 and backend is all APIs and stateless. JWTs obtained from Firebase Authentication are used for authentication. As such, when a user arrives on the home page, I have no way of knowing who the user (potentially) is and whether they are logged-in, till the time the user goes to the PWA (at /app).
When the user goes to the home page of my web app, I want the (stateless) server to be able to redirect them to the PWA if they have logged-in in the recent past (say 2 days). This can be achieved simply by the presence/ absence of a cookie, but I would also like to be able to show them a personalised greeting when /app page loads up.
Very open to suggestions for a better way to achieve this.
We are using C# MVC with Entity Framework and custom authentication implementing OWIN to make authentiation available by a custom user database.
Users login and authenticate themself by username and password by a standard login form.
To fit common security messurements OWIN regenerates the ".AspNet.ApplicationCookie" on each login and logout, I also force the "SessionIDManager" to regenerate a new Session ID (saved in .AspNet.ApplicationCookie) on each authentication change.
We use QUALYS to test the application for well known attack scenarios such as XSS, Session Hijacking etc. One imortant technic is to issue and validate Antiforgey Token which will be placed inside the form field AND inside a cookie stored on the client. As I unterstood these do not have to match since they are encrypted and get verified after decrypted on serverside on POST request (with ValidateAntiForgeryToken Attribute).
As mentioned above we use QUALYS to cover possible vulnerability scenarios. The report mentioned a security issue with the "__RequestVerifiationToken" which is set in the cookie and will not be regenerated until it gets invalidated by time. I reproduced this by tracking the traffic with Fiddler.
So the Token are there, get verified and I can log in, log out, chagne password and so on.
My question is, is there a build in possibility to reissue a __RequestVerifiationToken for the cookie?
When using the HtmlHelper #Html.AntiForgeryToken() it regerenates a new token for the hidden form field on each reload, but the cookie value keeps the same over time. I need to regerenate the cookie __RequestVerifiationToken value as well, at least on login / logout actions.
A side question is why internet explorer (Edge) requests result in a long time request when I manipulate the hidden form field content, firefox instead gets the error that a AntiForgery Erros occured?
I'm developing a web application and I'm having difficulties in implementing a log in feature.
In my application, a user has to log in to add a new item(row to a database and corresponding user id is added to the newly created row). Also, the user can navigate to different pages in the application, which all requires the user to be logged in. So, once the log in is successful the user id can be stored in a cookie file to share it with all pages. But I realized that, an user after using his credentials to log in, can then alter the cookie file and change user id in the cookie to someone else's and then view confidential data of the another person. How to prevent this type of attack ?
PS: I'm using servlets and JSP for my app.
An approach would be to, instead of storing the user id in a cookie, store an authentication token in the session cookie; this token needs to be unique per user and very difficult to guess. For this you could hash and salt the user id to generate the authentication token.
For extra security, make sure that the token expires at the end of the session or after the user logs out.
It would also help to do this over HTTPS, so that your traffic is encrypted.
Here is a very good guide to web based authentication.
I have been through much of the documentation and examples provided, but Im looking for some inputs for my setup from other users.
I have a some clients (website, iOs/Android apps). These only serves as a shelves and its content will be requested through servicestack, which makes servicestack a central point of my setup.
The client will login through servicestack and get a sessionid.
My question here is, how should i setup servicestack to make sure that the user is validated on each request?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted). Then on each request based on the session id, i check the cache to see if the user exists. If the user exists, the request i authenticated, and if not the user have to login again.
Am i on the right track here, or is there an easier way in servicestack, to support this?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted).
It sounds like you can just use the Authentication/Authorization plugin. Once a user is authenticated (using any of the 'Providers') the user's session is stored in the cache using the key 'urn:iauthsession:[sessionId]' and contains a bool property isAuthenticated. For any Service the requires Authentication you can use the Authenticate attribute.
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.