CoderZone.org
Pages: 1 « previous     next »
  Print  
Author Topic: Encrypting Passwords....now of little use?  (Read 6968 times) Bookmark and Share
Max
Jr. Member
*****
Posts: 75



View Profile WWW
« on: Feb 09, 2011, 11:35:33 am »

An interesting comment I found on Slashdot...

"It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be. Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

With all that aside, here's the thing: If an attacker has full access to your site (i.e. root-level access), it doesn't matter if your passwords are encrypted or not.  As mentioned above, they have access to all the info they need to crack the passwords, but it's simpler than that: if they want to they can save the password hash, insert their own, and then login to do whatever they want. If they feel like it they can replace the password later, leaving no one the wiser.

Given the relatively easy "crackability" of encrypted passwords with the tools available these days, what's the compelling reason to encrypt passwords anymore? It seems more like a "feel good" measure that, in the end, doesn't really seem to prevent or protect anything.
Logged
UnrealEd
Newbie
*
Posts: 22



View Profile
« Reply #1 on: Feb 09, 2011, 12:02:18 pm »

I agree.

To me the only useful reason of hashing/encrypting passwords is to provide a little privacy towards the user, but in the end it doesn't matter at all.

I also don't understand the fuzz about SALTs, what's the advantage of using a salt? There are numerous rainbow tables available, so, regardless of the salt, you will find a matching password. At the moment I use salts because everyone uses it, and because everyone says it's better. I can't see why, though.
Logged
Max
Jr. Member
*****
Posts: 75



View Profile WWW
« Reply #2 on: Feb 09, 2011, 12:58:51 pm »

To me the only useful reason of hashing/encrypting passwords is to provide a little privacy towards the user, but in the end it doesn't matter at all.

I'm not sure what you mean by privacy for the user...?

I also don't understand the fuzz about SALTs, what's the advantage of using a salt? There are numerous rainbow tables available, so, regardless of the salt, you will find a matching password. At the moment I use salts because everyone uses it, and because everyone says it's better. I can't see why, though.

I think the salt will alter the output of the hash, so it would (could) help defeat rainbow tables as I understand it...but if they have access to your site, they don't need a rainbow table. They don't need to crack the password, so it's kind of a moot point.

I've thought about this a bit over the last few weeks, and I (tentatively) don't think I'm going to bother encrypting passwords in the database anymore. There just doesn't seem to be a point to it now. A few years ago I would have screamed bloody murder had anyone suggested not encrypting passwords, but things have changed. If someone has rooted my site, encrypted passwords are really just a minor inconvenience to them, not a show stopper.
Logged
UnrealEd
Newbie
*
Posts: 22



View Profile
« Reply #3 on: Feb 09, 2011, 03:32:36 pm »

I'm not sure what you mean by privacy for the user...?
What I mean is when I look at my "members" table, I won't be able to see their passwords, that's all. The same goes for any hacker that gains access to my server. They will be able to do harm to my server, my website, my application, but they won't be able to use the information on other servers (knowing that many users use the same password on different sites).


I think the salt will alter the output of the hash, so it would (could) help defeat rainbow tables as I understand it...but if they have access to your site, they don't need a rainbow table. They don't need to crack the password, so it's kind of a moot point.
lol, while I was typing why I thought salts didn't make sense, I kinda figured out why they do  Tongue
It does indeed provide protection against rainbow tables, but like you said, when they have access to your server, there's no stopping them.


I've thought about this a bit over the last few weeks, and I (tentatively) don't think I'm going to bother encrypting passwords in the database anymore. There just doesn't seem to be a point to it now. A few years ago I would have screamed bloody murder had anyone suggested not encrypting passwords, but things have changed. If someone has rooted my site, encrypted passwords are really just a minor inconvenience to them, not a show stopper.
It's definitely something worth thinking about... I've been trying to come up with proper reasons to encrypt passwords for half an hour now but I still haven't found a single one...
Logged
cuberat
Newbie
*
Posts: 40


View Profile
« Reply #4 on: Feb 09, 2011, 05:09:15 pm »

I thought a lot about this, and I'll probably continue to encrypt passwords because I already have code that does it.

Smiley
Logged
Max
Jr. Member
*****
Posts: 75



View Profile WWW
« Reply #5 on: Feb 09, 2011, 07:04:07 pm »

One of the main reasons I'm considering for not doing it is the ease with which you can allow a user to recover their (unencrypted) password. Yes, you can always set a new password and mail it to them but 99 times out of 100 they'll just change it back to whatever it was to begin with.

And yes, you can always decrypt their password and send it to them, but that doesn't address the reason(s) for encrypting it in the first place. I'm just not sure it means anything anymore. Given the ease with which they can be broken it's like locking stuff up in a safe and then leaving the combination taped to the door. And once someone has breached your site it's all academic....so I'm leaning towards not doing it anymore, which is a big change for me. I just can't see the point. 5 years ago, yes, but now...?


I thought a lot about this, and I'll probably continue to encrypt passwords because I already have code that does it.
Logged
phpMan2010
Newbie
*
Posts: 32



View Profile
« Reply #6 on: Feb 10, 2011, 06:45:02 am »

I think it is good to have the reset function change the password, for client-side security.  Lots of people have cookies that contain their login information.  The cookies often live much longer than they should, especially on shared computers, and if you request a new password, resetting it makes it a little more difficult for someone to hijack the account.

The complexity of passwords is important, too.  Forcing users to create passwords that include upper and lowercase letters, digits, and symbols makes it more difficult for people to guess the passwords. 

From a user perspective, I prefer a reset on my password recovery, because it makes me feel more 'secure'.  Since the application logic to do a reset is simple, that's the approach I use.

The ease of password recovery has a huge impact on how I work with a site/provider/application.  For the billing interface of my web hosting provider, there's one account that I can never remember the password.  I just reset it every time I need to make an update, which is very rarely, less than once a year.  I reset it a couple of weeks ago, forgot to log in, and still have no idea what it is.  On other accounts, I'm using generated passwords which are impossible to remember, and I just have yellow stickies with the passwords, but not the account/username. 
Logged
Tags:
Pages: 1
  Print  
 
Jump to: