I intend to use SSL on the login form so that the username and password is encrypted during user login.
But, after the user has been authenticated, if I return to HTTP, the Autentication Cookie will be passed from client to server on each request. How safe is this? Obviously i'll use SSL on pages where the user is entering sensitive information, but for most of the time, for performance reasons, i'll just want them to remain authenticated and use HTTP.
I note that if I set RequiresSSL="True" in my forms authentication section in web.config then the authentication cookie is not passed if I use HTTP so I cannot identify the current user.
I guess my question is:
"Is it bad practice to set RequiresSSL="false" and allow the Authentication cookie to pass over HTTP"?
The forms authentication cookie is encrypted and checksumed with the machine key for your server if you set protection="All", so it's not particularly bad to drop back to HTTP.
Related
I'm learning about Basic Authentication and Jwt Authentication with Java and Spring and I want to ask you if basic authentication is a session based authentication?
I know that in a session based authentication, when the client log in, a sessionId is stored in cookie on the client browser and after that when the client make another request, the server compares the sessionId with the data stored in the memory of the server. And also I want to ask you how is the sessionId sent from client browser to server? Is it sent in the header like a token or how?
And the last question is how the server validate the Jwt token? I know that in case of session authentication, the sessionId sent from client is compared with the data from the memory of the server. But what's happen in case of Jwt authentication? The token is sent with the header and I know that the server validate it and there is no data in the memory of the server. Then how the server compares the token? Any feedback will be apreciated! Thank you!
if basic authentication is a session based authentication?
I know that in a session based authentication
well then why do you ask?
Actually - basic authentication means, that the user credentials(username and password) are sent in the Authorization http header
Authorization: Basic base64(username:password)
The server may or may not use a session cookie. Session cookie may be used with other authentication means or even without any authentication
how is the sessionId sent from client browser to server?
As a session cookie A session cookie is sent as an http header which browser treats as session-persistent
And the last question is how the server validate the Jwt token?
The JWT token should be signed. Note the token has usually 3 parts
header.body.signature
the header specifies a signature type (an asymmetric key or shared secret) and the signature is authenticated (signed or hmac-ed) header and content.
So - the server must validate the issuer, expiration and the signature.
So the server (service provider) doesn't need know the client's identity upfront. The service provider needs to know the issuer's (authentication service which issues the jwt token) public key or shared secret key.
After the jwt validation the service can assume the caller's identity based on the information in the jwt token.
why Jwt is more recommended?
It depends in the use case. (everything has its pros and cons)
I'd recommend using jwt in a distributed and/or microservice architecture. The service doesn't need to access the credentials or to authenticate the user.
In the basic authentication we need to send the username and password for every request.
In the session authentication we will send username and password at initial request. Then from server response we get the session id which stores in browser and gonna use that for requests.
In the token authentication we will send username and password at initial request. Then from server response we get the token and gonna use that for requests.
hope u got it!!
How can we prevent cross-site request forgery (CSRF) attacks in ASP.Net webForm. i want to secure some of pages in website and also how can we prevent if we received URL in the Email, from the attacker to perform CSRF.
You can take some extra precautions.
First connect your user authentication and actions, with the IP and the browser information's. So on each action, also verify that the actions are done from the user that have all that criteria.
encrypt some critical data/variables (that CSRF have to change) - and not let the variables only pass from SSL but plain text -
always use encrypted SSL cookies. requireSSL=true.
Do not allow cross app redirects enableCrossAppRedirects=false
Use one database table, to connect each authentication cookie with user actions like the log-out, so you know that the cookie is (maybe ?) logged out, or inactive, or something - even if its valid.
Block in advanced blocked ips that they have found that attacks.
http://www.phoenixlabs.org/pg2/
Is there a way to remove the authentication cookie, or sign a user out once they are removed from the asp.net membership database? By default if a user is removed from the database, the user can still browse the website since they still have a valid authentication cookie.
I've tried different things within global.asax but nothing seems to work. Is something like this even possible?
See here: FormsAuthentication.SignOut Method. Although this refers to users not being logged out server side, a similar approach can be used for managing deleted users.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie. To improve security when using a forms authentication cookie, you should do the following:
Use absolute expiration for forms authentication cookies by setting the SlidingExpiration property to false. This limits the window in which a hijacked cookie can be replayed.
Only issue and accept authentication cookies over Secure Sockets Layer (SSL), by setting the RequireSSL property to true and by running the entire Web site under SSL. Setting the RequireSSL property to true ensures that ASP.NET will never send an authentication cookie to the browser over a non-SSL connection; however, the client might not honor the secure setting on the cookie. This means the client might send the forms authentication cookie over a non-SSL connection, thus leaving it vulnerable to hijack. You can prevent a client from sending the forms authentication cookie in the clear by running the entire Web site under SSL.
Use persistent storage on the server to record when a user logs out of the Web site, and then use an application event such as PostAuthenticateRequest event to determine whether the current user was authenticated with forms authentication. If the user was authenticated with forms authentication, and if the information in persistent storage indicates the user is logged out, immediately clear the authentication cookie and redirect the browser back to the login page. After a successful login, update storage to reflect that the user is logged in. When you use this method, your application must track the logged-in status of the user, and must force idle users to log out.
The third option is the most secure but requires the most effort. IMO, the first two do not resolve the issue adequately.
It is also possible to store custom information in the Forms Authentication Ticket. You could store the last explicit logout time in this ticket, and check it against your server side database record. Please note that if this record is at user level instead of session, then all logins under that account would be logged out at the same time.
In your case, if you are deleting server side user and session records, as the record does not exist you will be able to also fail the authentication request.
I'd advise also storing and checking the last date/time the password was changed - that way if a user updates their password then all existing sessions are logged out.
My understanding is that ASP generates a cookie to authenticate a session. However, if that cookie is sent back and forth over a non https channel, can't I spoof it simply by spoofing the cookie? Can the cookie be locked to a particular IP or other machine fingerprint?
Sessions in ASP.NET aren't authenticated - authentication is entirely separate. By taking a session cookie and recreating it yes you can hijack the session, and if you lift an authentication cookie then you can authenticate as a user (which is why, by default, authentication cookies expire) - see http://msdn.microsoft.com/en-us/library/ms178581.aspx
The security note is quite clear;
SessionID values are sent in clear text, whether as a cookie or as
part of the URL. A malicious user could get access to the session of
another user by obtaining the SessionID value and including it in
requests to the server. If you are storing sensitive information in
session state, it is recommended that you use SSL to encrypt any
communication between the browser and server that includes the
SessionID value.
At my last job we worked around this by tracking the user's session ID (we appended a guid to the URL as a query string, there are other ways) in a database where we would also store the ip address which made the request. For all subsequent requests (anything with a session ID, a requirement to get any sensitive information) we simply check the session ID and the ip making the request against the values stored when we authenticated and set up the session. Request.UserHostAddress is a little harder to spoof. There is some overhead, but it is way more secure than cookies.
I am developing an API as a middleman between a Windows app and the database. The webserver will just be an ASP. NET generic handler returning json.
Users will log into the app and their credentials will be transmitted over the wire. From there what I was going to do was generate a session key that the app could use from then on with every request.
This will not be an open API in the foreseeable future.
Now what I am wondering is if this is secure enough? How can I stop people from using fiddler to just replicate the calls?
Is there a better approach to this? Would it help if I used SSL?
I don't want to complicate matters by using oauth.
Thanks!
Use SSL. In order to obtain the session token the client should authenticate himself with a username and password transmitted over SSL. Once authenticated the token should be transmitted to the server over SSL to prevent from man-in-the-middle attacks.
So here's the flow:
The client sends his credentials (username and password) over SSL to a web method
The web method verifies the credentials and generates a session token and returns this session token to the client.
The client sends the session token on subsequent requests to protected resources.
The server verifies the token and if valid grants access to the protected resource.
You use simple Forms Authentication to generate the session tokens. The FormsAuthentication.Encrypt and FormsAuthentication.Decrypt methods could be a good start for you. The forms authentication token contains an encrypted value of the currently authenticated user. If you are running in a web-farm make sure that you have static machine keys on all nodes of your web farm, otherwise a session token encrypted on one node might not be decrypted on another node.
As an alternative to session tokens you could use basic authentication over SSL. The drawback is that credentials are sent over the wire on each request. Even if you are using SSL, the password is still transmitted over the wire, so this method is less secure than session tokens but easier to setup.