VB.Net Saving a hashed Password

you set a persistent cookie

bool persist = true;
var cookie = FormsAuthentication.GetAuthCookie(loginUser.ContactId, persist);
cookie.Expires = DateTime.Now.AddMonths(3);
var ticket = FormsAuthentication.Decrypt(cookie.Value);
var userData = "store any string values you want inside the ticket that will be encrypted"
var newTicket = new FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, userData);
cookie.Value = FormsAuthentication.Encrypt(newTicket);
Response.Cookies.Add(cookie);

Select allOpen in new window

you read the cookie

string userId = null;
if (this.Context.User.Identity.IsAuthenticated) 
{
    userId = this.Context.User.Identity.Name;
}

Select allOpen in new window

http://bit.ly/1OitGRi

Thanks for the reply David.  I forgot to mention that this was a windows forms app.  Is this still method appropriate?

Then WHY have a userid/password in the first place if you don't want the user to use it. In a windows application you already know the users identity and within your application you can allow/disallow the user to do things based upon their identity.

In answer to both of you: I work for a customer using pcs for several users and they don't necessarily switch Windows sessions, so there is a user database additional of active directory and application logins.

David Johnson used cookies, which obviously is a solution for web apps, but you can store the same data in user registry, can't you?

The general solutions browsers do to autofill form controls is even worse storing values unencrypted. Each user registry is only readable for a user, (though that does not apply in my case, astwo users might share a windows account), but that's obviously not very secure. Site with remember me feature rather store a cookie and in best cases with some encrypted info.

Anyway, if users always work in their own windows account you can simply check Environment.UserName (loggeed-in user) or (think of processes started with RUN AS) System.Security.Principal.WindowsIdentity.GetCurrent().Name

The current WindowsIdentity has more than just the username in other properties, but also in the Name property you have the Domain/Username.

Bye, Olaf.

Simple really, not all users are on the same domain and act some are on stand alone devices in different areas of the country.  Additionally, some users may well log into the app from shared devices that they have not logged in to.   By far the simplest way would be an individual log in per user.  Which was the original question.

Thanks Olaf, please see my later comments above. Apart from the different domains, it is the different windows sessions that creates the problem.  David's comment as to WHY seems to be obvious in its answer.  The data is confidential and I'm looking for the safest way.   I couldn't imagine that there wasn't a windows app somewhere that hadn't come across this problem somewhere.   In regards to your comments re the registry, yes of course the password could be stored there but would not be secure in all the different scenarios I have mentioned.    From your comments I'm thinking that under the circumstances, maybe the best might be encrypting the password, saving it to the registry and then decrypting it before checking at log in.  Not great though

Actually, just thought, even that wont work if the user logs in from another machine.  Would have to be in the DB!!!!