What’s the point of hashing passwords over an insecure connection?

[implicated]

I've been working in the integration of SMF to my own users' management system, and I have some doubts about the proper way to send and receive users' data. 
It's a common practice to save in the database hashed or md5ed versions of passwords, and I've been wondering what the point of doing this is, although I recognise I have done it myself and smf has a quite complex function to perform this task.

Unless you're using a secure connection, which it's not usually the norm, passwords are sent over an open connection, meaning that theoretically anyone can get access to the information sent over this connection and users send their passwords as plain text, if a hacker can capture this connection, she'll get the password, unless the password itself it's hashed. On the other hand, if passwords are hashed, the hacker will get a hashed version of the password, this can be performed on client side by using a JavaScript version of md5 or similar hashing algorithm, but then again, the hashed version will travel over an insecure connection, anyone could then get access by sending the hashed version of the password which will match the one stored in the database.

Also, I reckon it's pointless to hash passwords stored in the database since if a hacker or a malicious employee gets access to the database, will not only get access to the specific column where passwords are stored, but to the whole table or database, the only protection offered here is for users who use the same password for everything, for instance, their email accounts.

Perhaps we could also send an unintelligible version of user data, let's say we use JavaScript to hash both username and password, then we concatenate both using a fixed concatenation string, something like

Code Select Expand


Hashed username: 851c396b5b7bb83452e19567836ed7f3
Hashed password: 5bf4ec8db1d13c79edfae0699ce662fe
Concatenation string: |an15tr1ng| or maybe just |

This way we'd be sending just one string:

Code Select Expand

851c396b5b7bb83452e19567836ed7f3|an15tr1ng|5bf4ec8db1d13c79edfae0699ce662fe

Which is more unintelligible but still prone to be hacked, or maybe without using a concatenation string, i.e., just:

Code Select Expand

851c396b5b7bb83452e19567836ed7f35bf4ec8db1d13c79edfae0699ce662fe

This should be even more unintelligible, and we know the first 32 chars are the username and the rest are the password, however, if our hacker knows the structure we are using, he'll get access promptly, perhaps a secret structure would work, nonetheless this should be easy to implement for everyone without the need of editing scripts to customise functions. A session variable could also help, at least we can make sure the user is logging in from a script hosted on our server; let's say we use this;

Code Select Expand

$secret_session_var=mt_rand ();
$_SESSION['secret'] = dechex($secret_session_var);

Let's suppose $secret_session_var equals 1604716014 then $_SESSION['secret'] equals 5fa605ee, that will be our secret key for the length of the session. Then we send this value on the login form as a hidden field, which, certainly anyone can see, but it'll be only valid for the current session. We use Javascript to hash both username and password and the user should submit with the form just a long string containing both, username and password;

Code Select Expand

Hashed username: 851c396b5b7bb83452e19567836ed7f3
Hashed password: 5bf4ec8db1d13c79edfae0699ce662fe
Secret key: 5fa605ee //$_SESSION['secret']

The form should return: Hashed username+Secret key+Hashed password; or the combination you like, something like:

Code Select Expand

851c396b5b7bb83452e19567836ed7f35fa605ee5bf4ec8db1d13c79edfae0699ce662fe

Where the first 32 chars are the username, then the 8 char session key and then the 32 char password. Once we get it on the server we'll have to unscramble it and contrast username, password and secret key. Far from being a bullet proof system, it does provide additional security and makes hackers' work a bit harder. The cons here are the use of JavaScript to hash the user input, it should be working otherwise they shouldn't be able to login, of course, if JavaScript is not available, the script can also receive plain text username and password and login the user with no security at all.

To summarize, unless anyone can prove otherwise, if security is a must, the only way to achieve it it's using a secure connection, or does anyone have any other idea?

[[Unknown]]

I've been working in the integration of SMF to my own users' management system, and I have some doubts about the proper way to send and receive users' data. 
It's a common practice to save in the database hashed or md5ed versions of passwords, and I've been wondering what the point of doing this is, although I recognise I have done it myself and smf has a quite complex function to perform this task.

Simply put:
1. It means the administrator has no way to know what the passwords are.
2. It means any hacker that gains access to the database has no way to know what the passwords are.

It's not whether it's sent over in clear text that the hashing is trying to change, it's how it's stored.  Do you store clear text passwords on your hard drive, anywhere?  I sure don't.

Cookies are also hashed, meaning that only logins are, in 1.0 (1.1 hashes logins with JavaScript) clear text.

Typically, it's more common for a hacker to get into the database, either through a hole in some other software or even in the forum software, than for them to tap into your connection itself.

You may wish to look into "challenge" logins.

Also, I reckon it's pointless to hash passwords stored in the database since if a hacker or a malicious employee gets access to the database, will not only get access to the specific column where passwords are stored, but to the whole table or database, the only protection offered here is for users who use the same password for everything, for instance, their email accounts.

Wrong.  Even though the password I use here is unique, I would be APPAULED if any other person with access to the database - and there are a few - could see my password.  I don't want anyone to know my password, except me... even if they could change it.

If I were made aware that my password would be stored in clear text on a forum, I would not register on that forum, unless I needed to - and then, I would do it with a dummy account, and avoid any personal information anywhere, and set my pm ignore list to everyone.

To summarize, unless anyone can prove otherwise, if security is a must, the only way to achieve it it's using a secure connection, or does anyone have any other idea?

Assuming that I can tap into your connection, that may be true.  In practice, it's much less common than you imply.

Please do not bump your topics, especially after 6 minutes.  I'm not even sure why you posted the second reply, except to annoy me - I was posting this innocently and had to get notified of your duplication of your last line.

Forgive me, but every single time I've seen this train of comments or argument, it's ALWAYS someone trying to rationalize throwing away security, hashing, and etc... and, there's ALWAYS that part of why they want to do it - they want to see the passwords.  Deny, deny... but I hope that's not where you going because there ain't a chance.

-[Unknown]

[implicated]

Cookies are also hashed, meaning that only logins are, in 1.0 (1.1 hashes logins with JavaScript) clear text.

Typically, it's more common for a hacker to get into the database, either through a hole in some other software or even in the forum software, than for them to tap into your connection itself.

You may wish to look into "challenge" logins.

I didn't know they were js hashed, that's great! I know the db is more prone to attacks, but usually that happens because of human nature, doesn't it?

Also, I reckon it's pointless to hash passwords stored in the database since if a hacker or a malicious employee gets access to the database, will not only get access to the specific column where passwords are stored, but to the whole table or database, the only protection offered here is for users who use the same password for everything, for instance, their email accounts.

Wrong.  Even though the password I use here is unique, I would be APPAULED if any other person with access to the database - and there are a few - could see my password.  I don't want anyone to know my password, except me... even if they could change it.

If I were made aware that my password would be stored in clear text on a forum, I would not register on that forum, unless I needed to - and then, I would do it with a dummy account, and avoid any personal information anywhere, and set my pm ignore list to everyone.

That's because you and me know it but most of the regular users don't even realise it, I don't even have a paypal account because I'm afraid of the way they handle data and they're supposed to be really serious.

To summarize, unless anyone can prove otherwise, if security is a must, the only way to achieve it it's using a secure connection, or does anyone have any other idea?

Assuming that I can tap into your connection, that may be true.  In practice, it's much less common than you imply.

Please do not bump your topics, especially after 6 minutes.  I'm not even sure why you posted the second reply, except to annoy me - I was posting this innocently and had to get notified of your duplication of your last line.

Forgive me, but every single time I've seen this train of comments or argument, it's ALWAYS someone trying to rationalize throwing away security, hashing, and etc... and, there's ALWAYS that part of why they want to do it - they want to see the passwords.  Deny, deny... but I hope that's not where you going because there ain't a chance.

-[Unknown]

I didn't mean to annoy you or "throw away security", it's just that my question at the end of the post somehow got lost, I can't see last line duplication, it just got lost, if I posted this here was because I was and I am really interested in getting opinions about this matter an I thought this could benefit everybody, sorry, I promise I'll look somewhere else to post it, I don't mean to be paranoic but this is an issue that could be solved by joining ideas, at least, that's what I think. But don't worry I'll not interrupt your dreams anymore. By the way, your passwords are safe, I'm not interested in them 

[[Unknown]]

Also, I reckon it's pointless to hash passwords stored in the database since if a hacker or a malicious employee gets access to the database, will not only get access to the specific column where passwords are stored, but to the whole table or database, the only protection offered here is for users who use the same password for everything, for instance, their email accounts.

It's most common to expose READ access to the database inadvertently, for whatever reason.

For example, if I somehow got access (read only) to your database, and your passwords were in clear text, all I would have to do is look for the ADMIN password, and BAM.  I have administrator access, not just read access to the members table.  Livin' large.

I didn't mean to annoy you or "throw away security", it's just that my question at the end of the post somehow got lost, I can't see last line duplication, it just got lost, if I posted this here was because I was and I am really interested in getting opinions about this matter an I thought this could benefit everybody, sorry, I promise I'll look somewhere else to post it, I don't mean to be paranoic but this is an issue that could be solved by joining ideas, at least, that's what I think. But don't worry I'll not interrupt your dreams anymore. By the way, your passwords are safe, I'm not interested in them 

No, I meant you posted:

To summarize, unless anyone can prove otherwise, if security is a must, the only way to achieve it it's using a secure connection, or does anyone have any other idea?

Six minutes after the original post.  That's what annoyed me.  To have someone reply to their own topic with the last line of their last post in the topic, after only six minutes... well, I already consider bumping to be rude.

-[Unknown]

[implicated]

t's most common to expose READ access to the database inadvertently, for whatever reason.

For example, if I somehow got access (read only) to your database, and your passwords were in clear text, all I would have to do is look for the ADMIN password, and BAM.  I have administrator access, not just read access to the members table.  Livin' large.

That's very positive. That's the sort of answers I was looking for, I had not realised or I didn't recall that admin pass word was also stored in the db, good point. Maybe I'll consider moving it out the db.

[Amacythe]

[Unknown], I had missed that last line of the initial post.  The post itself has a scrollbar which I didn't notice. I assume that implicated thought the last bit had truncated.