Storing user password in the clear? No thanks.

Topics: ASP.NET 2.0
Dec 17, 2007 at 7:52 PM
Edited Dec 17, 2007 at 9:25 PM
Does storing your password in the users.xml file without encryption bother you? It definitely bothers me so I sent an email to Mads asking him about this topic. He mentioned to me that some people didn't like storing the password in an encrypted format. Seems strange to me but okay.

Mads also mentioned that they were thinking of bringing back encrypted passwords in the 1.4 release. I sure hope so. In the meantime...

Personally I don't like the idea so I went looking for an alternative membership provider that would offer me the encrypted storage feature. I was able to locate a pretty darn nice provider and switched over my membership this weekend. Now I can sleep a little better knowing that if someone figures out how to extract my users.xml file then they can't see my password...

I wrote more about this on my blog http://www.dscoduc.com/post.aspx?id=b297af99-6c0f-426b-a41a-bc6cf76c559a
Dec 17, 2007 at 8:04 PM
This is just what I needed. I had been looking through the codeplex projects but hadn't taken the time to try implementing anything I had found. Good to know this one works. It was either use a different membership provider or attempt using the cryptography application block from the MS EntLib to encrypt the elements in the current provider. I have a custom built encryption control used for another project but it is one way only with no ability to recover the forgotten passwords.
Dec 18, 2007 at 3:47 AM
You guys are aware that nobody can access App_Data except you, right? Thus encrypting its contents is pretty pointless...
Dec 18, 2007 at 4:11 AM
I'll be sure to point that out to the Web Hosting Provider administrators. "You guys can't access my App_Data folder!"

No, I don't think I can rely on that to keep prying eyes out of my files. But you are free to leave it in the clear.

By the way, would you like to host your blog on my servers? I promise not to look in your App_Data folder... wink wink...

8~)

CHris
Dec 18, 2007 at 5:31 AM
Edited Dec 18, 2007 at 5:53 AM
I administrate a blog for a police department that uses it to provide press releases and soon to manage their entire site. Because of the level of trust by the public put into the information posted, any possibility of tampering could be rather embarassing, or potentially dangerous to the police department and the city it serves. Of course the post and page files themselves could be directly tampered even if stored in a SQL database by whoever at the hosting company has DBA access, but for the sake of peace of mind to my supervisors and creating one more level of security, password encryption goes a long way, especially when people tend to use the same password for more than one login.
Dec 18, 2007 at 12:47 PM
I understand both parts of the 'argument' here... how about an option to encrypt passwords, or to not encrypt passwords. But make it a one way deal... once you encrypt you can't go back (at least not automatically), if they want to do it manually they can...

Dec 18, 2007 at 5:27 PM
Edited Dec 18, 2007 at 5:28 PM
If you have access to my App_Data folder, then you have access to my App_Code folder, and you can see the decryption algorithm and just run it. Or at the very least you can see the encryption algorithm, choose a new password, run the encryption algorithm on it, and change the encrypted password to the new encrypted password. Or you can change the admin pages to no longer check for authentication.

Really, this is fairly stupid. If they don't have access to App_Data, you're fine, and encryption is pointless. If they do have access to App_Data, you're screwed no matter how many layers of security you put into the blog software.
Dec 18, 2007 at 5:43 PM
Not totally accurate, as I pre-compile my website so it would still be semi-hidden.
Dec 18, 2007 at 5:49 PM
Edited Dec 18, 2007 at 5:52 PM

Domenic wrote:
If you have access to my App_Data folder, then you have access to my App_Code folder, and you can see the decryption algorithm and just run it. Or at the very least you can see the encryption algorithm, choose a new password, run the encryption algorithm on it, and change the encrypted password to the new encrypted password. Or you can change the admin pages to no longer check for authentication.

Really, this is fairly stupid. If they don't have access to App_Data, you're fine, and encryption is pointless. If they do have access to App_Data, you're screwed no matter how many layers of security you put into the blog software.


I understand what you are saying but at the same time, using that logic then why would anyone encrypt anything? Obviously it is possible to decrypt if you can encrypt unless you have no intention of retrieving the encrypted information, or at least running a comparison against other encrypted information. As they say with locks can be said with encyption, it only keeps "an honest man honest." But I will quote myself since it is the most important part of what I said earlier: "for the sake of peace of mind to my supervisors." To the technologically inept, it makes them feel better. And secondly "people tend to use the same password for more than one login." Yes, you could change the password but if you cannot retrieve it then you can't use it to try someone's personal banking login. It is a precaution.
Dec 18, 2007 at 5:59 PM
Well I didn't mean to start a flame war. I just felt that it was strange to have my password in clear text in the xml file. I understand that someone can hijack my page, change the authentication method, whatever. What I don't like is that an administrator can casually glance at my users.xml file and immediately see my password. If you are fine with it, then great. If you are not fine with it then the alternative provider might work better for you. Personally, I don't think it's pointless.

Cheers!
Dec 18, 2007 at 6:01 PM
Oh, and I almost forgot...

If the world stopped spinning we would all float out into space.

It's hard to prepare/mitigate all risks. For those that we can deal with then it's best to do what is possible. Remember the whole defense in depth theory?
Dec 18, 2007 at 6:10 PM

dscoduc wrote:
Well I didn't mean to start a flame war.


I appologize if I came accross as flaming. I was merely trying to elevate the requirement so that I didn't need to have to implement a thrid party membership provider into an already excellent project.


Domenic wrote:
Really, this is fairly stupid.


I also don't appreciate my thoughts being considered stupid, but that's rather petty on my part to be concerned about such matters.
Dec 21, 2007 at 12:55 AM
Edited Dec 21, 2007 at 12:56 AM
I've noticed that nobody has mentioned the option of hashing the password and storing that in the XML file. If you hash the password (using SHA1, or something like that), then all you'd have in the file is a hash string, which is pretty much useless to anybody who does get a hold of the file, without actually revealing your password to them.

Would setting up something that not meet your needs? I'm configuring BE.NET to support multiple blogs/users on a single installation, and in my users table, I'm salting and hashing the passwords, which seems to be working just fine.
Dec 21, 2007 at 3:49 AM
That would work for me. The issue though, is not the ability to do so, as there are many ways to do this, but that the ability be a built in option for a default install of BE.
Jan 7, 2008 at 12:41 AM

rwmnau wrote:
I'm configuring BE.NET to support multiple blogs/users on a single installation, and in my users table, I'm salting and hashing the passwords, which seems to be working just fine.


rwmnau, would you mind posting your hashing solution? It seems exactly what I am looking for and I'd hope that such a simple solution could then be added into BE.NET very soon.
Jan 8, 2008 at 10:10 PM
Edited Jan 8, 2008 at 10:11 PM
The only modifications I made were a one-time hashing of the passwords in the XML file (I did this by hand, since I only had two users, but for your reference, that SHA1 hash of "admin" is "D033E22AE348AEB5660FC2140AEC35850C4DA997"), and then I modified the "ValidateUser", "ChangePassword", and "CreateUser" methods in the provider to use a derivative of the statement:

if (storedPassword == System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(typedPassword, "SHA1")) ...

instead of just a straight comparison of the typed password to the stored password.

I used this method because it takes care of the byte-array -> string conversion behind the scenes, and just returns me a string. Way easier, and since we're comparing it to a string in the end, it saves the headache.
Apr 15, 2008 at 7:00 AM
Understanding that the recent security issue has been address regarding the access of the users.xml file through the JavaScriptHandler wouldn't this bring more weight to the request of applying encryption to this file as a default or built-in option?
May 20, 2008 at 9:19 PM
I would definately prefer a web.config switch for selecting hashed / non hashed passwords.
And don't like passwords in the clear.

Thanks for those who did the work on the provider :)