"Remember Password" Checkbox

[atn]

I was wondering how I would go about doing this. What is the coding for this? Trying to do something extra that wasn't taught in the class. If anyone knows and could help, that'd be great. Thanks!

Anthony

[JerryShaw]

You are not giving much detail.
I assume you mean to save / store the password for this user if a checkbox is marked. Then when this user tries to log in the next time, you read back the password from whereever you stored it and use that instead of asking the user for the password.

So, store the username and password in a file (encrypted I hope), and on startup, if the file exists, load up the information.

// Jerry

[Narue]

>So, store the username and password in a file (encrypted I hope),
>and on startup, if the file exists, load up the information.
Ugh, no. Even encrypted, don't copy the password anywhere, period. Ideally you wouldn't even store it for authentication, instead favoring an irreversible hash[1]. The only place a string that can be restored to the original password should be allowed is the input box, and even then it should be discarded as quickly as possible.

You have the right idea though. Store some kind of identifying information for the user name that tells the application that this user's password is valid as long as it remains unchanged in the form on subsequent logins. That means poll for a TextChanged event and require a password for that session if it gets fired.

If you're properly masking the password in the input box then it really doesn't matter whether you put the right password there or not. Of course, if your system is even remotely secure, you wouldn't know the right password anyway. That's something only the user should have access to in any way, shape, or form. Just fill the box with enough garbage to make it look like there's a password there.

This way the password remains secure, even if the whole idea of "remember my password" isn't. ;) Just FYI, since this talk of security, hashes, and such is probably well beyond the OP at the moment. Also, somehow I doubt that the application the OP is writing a login for will even need security features.

[1] And when I say hash, I don't mean something suitable for a hash table. I mean a painfully slow, state of the art, cryptographically secure algorithm.

[JerryShaw]

Narue,

Help me understand your statement:

Ugh, no. Even encrypted, don't copy the password anywhere, period. Ideally you wouldn't even store it for authentication, instead favoring an irreversible hash[1]. The only place a string that can be restored to the original password should be allowed is the input box, and even then it should be discarded as quickly as possible.

Persistent storage of information is written to disk (aka file IO). No matter if you use MD5, hash algo, or any number of encrypting techniques. Even storing a value to the registry... guess where it ends up... on the disk. Guess where your local SAM account password is stored... on the disk, even if you are authenticated on AD, a copy gets placed into the local SAM in case you loose connection to the AD, you can log in locally. Persistent data means to store information in a media that will retain information without the use of external power.

I agree, storing passwords is an option that should be avoided, however it is done.
In many cases, the credentials are passed on to Database connections or many other sources requiring non AD credentials. In these cases your irreversable hash algo would not work.

So, if the application uses this "hateful" option.
I would expect that when the logon screen appears, it would first grab the account of the (Windows) currently logged on user, then go to my persistent source where I can search for this windows user. If found, I would place the associated login account (can be different than this Windows User account), and the encrypted password value (no matter how you want to label it, it is encrypted) onto the form. I would load the password field with 20 spaces (not the actual password) so 20 symbols are always displayed thereby hiding the number of character in the real password.

If the user just pressed the Ok button, I would decrypt the password long enough to send the credentials on there way, otherwise, (like you said) the credentials are reset/removed, and killed in the persistent storage area, and on the screen.

Personally, I prefer to use Active Directory for all authentication, and never store credentials anywhere. But we don't all develop for corporations, and most SMBs don't have AD, so this kind of request will popup. If you can not fend off the (paying) customer demand for this feature, be real careful on how you persist the data. Do not encrypt with a single key. Combine the Windows login name, and strong long key to handle the account name and password encryption.

My advice to the orginator of this thread... make them enter a password, drop the idea of "Remembering Passwords".

// Jerry

[Narue]

>Persistent storage of information is written to disk (aka file IO).
I think you misunderstood. I'm not saying never to store passwords, I'm saying never to store passwords in a form that can be reversed. That includes encryption, which in my experience typically means a reversible encryption.

>In many cases, the credentials are passed on
I was talking about storing a password for authentication purposes, not further using the password for other purposes or with differing authentication schemes.

>Personally, I prefer to use Active Directory for all authentication
Indeed. This is also a more user friendly option as you can lose the login dialog altogether and simply rely on Windows to authenticate the user for you. That's not always possible, but it's a good general approach.