In my web config file the maxInvalidPasswordAttempts is set to 3.
I have a change password form which allows the user to enter their security answer 3 times before the account locks out.
However i was wondering if its possible to pull out the number of tries left in order to display a relevant error message when the user tries for the third time.
Any ideas? Thanks in advance for your help.
You could keep the number of remaining tries in a Session variable, as is done here
Related
I'm completing the PCIDSS assessment.
The requirements state passwords must be changes at least every 90 days, and be different from any of the previous 4 passwords.
I'm not certain whether this is for access to the server, or to the application I provide to users on the server.
If it's the latter - is there anyway of enforcing this in an ASP.Net 3.5/4 web application, and in an MVC4 web application?
Thanks, Mark
Is this for an in house application? If so, consider integration with LDAP/Active Directory (assuming that's being used for your network passwords). That can then take care of the password rules (i.e. tracking what's been used before, making sure passwords are sufficiently complex & different from previous ones & enforcing change frequency). It also means your users won't have to remember/keep in synch multiple passwords, which they'll thank you for.
http://msdn.microsoft.com/en-us/library/ms180890(v=vs.80).aspx
For your first requirement, Asp.Net Membership has a property MembershipUser.LastPasswordChangedDate which you can then hook into your login like so:
if (Membership.ValidateUser(userName, password))
{
MembershipUser theUser = Membership.GetUser(userName);
if (theUser.LastPasswordChangedDate.Date.AddDays(90) < DateTime.Now.Date)
{
// Inform user password expired + redirect user to change password screen
}
FormsAuthentication.SetAuthCookie(userName, rememberMe);
}
The second requirement (viz cannot be the same as the last 4 passwords) you will need to implement yourself. At a suggestion, create a new table UserPasswordHistory foreign keyed back to aspnet_User.UserId with a containing a password hash, which gets inserted every time the user changes his/her password. You can then compare the hash of the new password with the previous 4 and reject accordingly.
You could save the passwords in another table, along with the date created. That would be fairly straightforward
'I m not certain whether this is for access to the server, or to the application I provide to users on the server.
generally PCIDSS focus on server so .. this is for the access to the server.
I want to limit concurrent access to internet or intranet web applications.
I want to be able to allow certain number of concurrent access, let's say I want to allow maximum 20 concurrent access using the same username.
I can imagine creating a session at the login time and save it into DB with incrementing a counter, but there is no way to delete it from the DB and decrement the counter if user is logged off, as user may just close the browser.
Guys, what is the best way from your opinion?
Thanks,
You are right in that you cannot know if a user just kills his browser or pulls the cord.
Create a timer that does an Ajax call every 30 seconds and log it. If a user isn't in this log for 60 seconds - throw'em out at the server.
This won't stop someone from leaving their browser open over the night and hogging a slot though.
There is another answer mentioning an "last active" field. This on the other hand messes up when someone needs to leave their browser open to look at something for more than the timeout limit of minutes.
If someone is thrown out due to the user/timeout limit; I think it would be nice to have them automagically logged in again totally transparently if there is a slot open again.
Without thinking too hard about it I believe this solution will give birth to other problems.
Edited away:
As I commented - 20 users - are you really solving the right problem?
You may wish to have a "lastactive" field on your session. When someone attempts to log in or otherwise create a session, you can query for all sessions that have been active within a period of time (say 15 minutes), and use the resulting count to tell you how many concurrent sessions are active.
I have a problem of the session not expiring. Here is my case
I have a application in asp.net1.1. i am able to handle session when user click logout button. Session is active for 35 minutes. the application is also check if same user is trying to login using multiple machine and blocks it.
Now this application is deployed in city where there is power outage. When user is loggd in and light goes off, the session remain open. Due to this, the user is not able to log in again for next 35 minutes from alternate machine.
Can you tell solution of how to handle issue of session remained open the right way?
Did you write the code that if a session already exists, refuse another login? If so, you will probably have to change it. It is more common to kill the old session and start a new one if necessary. I prefer to allow multiple sessions for a single user unless there is some specific security requirement not too.
Lookup the SessionState timeout field in Web.config.
Best solution is to add UPS to the client workstations so they don't lose the connection if the power goes out. The only other option I can think of in this situation is to add something to the login code which, instead of blocking an alternate location login, instead forces the other session to be expired on a successful login.
We solved some similar issue this way:
in the body of the asp.net page, we attach on the onload event an ajax call. In this ajax call, the session timeout is set to 35 mins.
Also an ajax call is attached to the onunload, where we set the session timeout to 1 min.
This way the user has 35 min timeout when using the application, yet has 1 minute timeout when closing the application.
I have two web applications and both are developed in ASP.NET. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS).
I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution?
Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works.
Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues.
I work with this sort of thing a lot. What you're looking for sounds like a candidate Single Sign-on solution or Federated Security.
You might try doing something similar to the following:
Create a simple db or other sort of table storage with two columns "nonce" and "username"
When you build the link to the other site create a GUID or other unique identifier to use as a one-time nonce, passing it as a querystring ?id=. Insert an entry into the table with the current authenticated username and the unique identifier you created.
When you reach the destination of your link, pass the unique identifier to call a webservice that will will match up the identifier with the username in the database you inserted before jumping to the second site (secure this with ssl).
If the nonce checks out with a valid username, you're all set. The webservice should remove the used entry and the table should stay more or less empty any time you are not in the middle of a transaction.
It is also good to include a datetime in your nonce/username table and expire it in 60 seconds or less to minimize the risk of replay attacks. We also require client certificates for external applications to call the webservice in order to verify the identity of the caller. Internal applications don't really necessitate using client certificates.
A nice thing about this is that it scales fairly well to as many sites as you would like to use
Not perfect security, but we've never had a significant compromise with a such as system.
As long as you have a good authentication system in place on the second website I think solution 2 is the one for you, taking into account the remark Andrew made about the sensitive ID's of course.
For more information on encryption: check the documentation of the FormsAuthentication.Encrypt Method . I think they even do something with writing a value in a cookie in that example.
If you put the userid in a query string and that's all the 2nd app uses to allow login, what's to keep me from manually typing in other users id's? You'd still have to prompt for password on the new site.
I'd use a database to hold login information, and have both sites reference that same db. Use it like you'd use a session.
D
I don't think 1) will work due to browser security (cookies from one domain cannot be read by another domain). I would go with 2), except I would encrypt the querystring value.
EDIT: For more info on cookie privacy/security issues, check out the "Privacy and third-party cookies" section here.
What are you using as the user's id? If you are using their social security number or email (something sensitive) then you are going to want to encrypt the value before you put it on the query string. Otherwise (if the user's id is something ambiguous like an integer or a GUID) it should be fine to put the id on the query string.
using cross domain, you can not SHARE the session, so I was thinking about POST
idea 1
if afraid of "showing" the username in the address, why not sending a POST?
<form name="myForm" action="http://www.mydomain.com/myLandingPage.aspx">
<input type="hidden" id="userid" value="myUsername" />
click here
</form>
but then... off course, "View Source Code" will show it
idea 2
then.. I remembered that I do the same, but sending a Encrypted string like:
http://www.anotherapplicationsite.com/somesuburl?userID=HhN01vcEEtMmwdNFliM8QYg+Y89xzBOJJG+BH/ARC7g=
you can use Rijndael algorithm to perform this, link below has VB and C# code:
http://www.obviex.com/samples/EncryptionWithSalt.aspx
then in site 2, just Decrypt and check if the user exists... if it does, continue, if not saying that the user tried to temper the query string :)
Is it possible for ASP.NET to mix up which user is associated with which session variable on the server? Are session variables immutably tied to the original user that created them across time, space & dimension?
To answer your original question: Sessions are keyed to an id that is placed in a cookie. This id is generated using some random number crypto routines. It is not guaranteed to be unique but it is highly unlikely that it will ever be duplicated in the span of the life of a session. Even if your sessions run for full work days. It would probably take years for a really popular site to even generate a duplicate key (No stats or facts to back that up).
Having said all that it doesn't appear that your problem is with session values getting mixed up. The first thing that I would start to look at is connection pooling. ADO pools connections by default but if you request a connection with a username/password that is not in the pool it should give you a new connection. Hint that may be a performance bottleneck in the future if your site is very large. It has been a while since I worked with SQL Server, in Oracle there is a call that can be made to switch the identity of the user. I would be surprised if there was no equivalent in SQL Server. You might try connecting to your DB with a generic username/password and then executing that identity switch call before you hand back the connection to the rest of your code.
It depends on your session provider, if you have overriden the session key generation in a way that is no longer unique, then multiple users may be accessing the same session.
What behavior are you seeing? And are you sure there's no static in play with the variables you are talking about?
while anything is possible. . . .
No, unless you are storing session state in sql server or some other out of process storage and then messing with it. . .
The session is bound to a user cookie, the chances of that messing up in a normal scenario is very unlikely, however there could be issues if using distributed session state.
It's not possible. Sessions are tied to the creator.
Do you want to mix up, or do you have a case when it looks like mixed up?
More information:
I've got an app that takes the userid/password from the login page and stores it in a session variable. I plop it into my connection string for making calls to SQL Server.
When a table gets updated, we're using 'system_user' in the database to identify the 'last updated by' user. We're seeing some odd behavior in which the user we're expecting to be listed is incorrect, and it's showing someone else.
Can you pop in the debugger and see if the correct value is indeed being passed on that connection string? It would quickly help you idenfity which side the problem is on.
Also make sure that none of the connection code has static properties for connection or user, or one user may have their connection replaced with that of the most recent user before the update fires off.
My guess is that you're re-using a static field on a class to hold the connection string. Those static fields are re-used across multiple IIS requests so you're probably only ever seeing the most recently logged in user in the 'last updated by'.
BTW, unless you have a REALLY good reason for doing so then you shouldn't be connecting to the DB like this. You're preventing yourself from using connection pooling which is going to hurt performance under high loads.