Password hashing locations.

[MrStonedOne]

Simply put, I'm in the middle of prepping for a move from phpbb to smf, and one of the first things I'm going to be doing is changing the password hashing algorithm from the horrifically insecure sha1 to something much better, haven't decided what as I'm still doing research.

I found the hashing stuff in loginlogout.php but I would need to know the locations of other places that change or validate a password. Since smf erroneously doesn't have a central password hashing/checking function, I have to find and change all of the locations that deal with a password

Anybody more familier with the code base want to help me out by pointing me to those locations.

I'm assuming there is one for changing password from profile, one for registering the account, one for admin changing passwords, one for resetting passwords, etc, on top of the login.

Sidenote: Please resist the temptation to derail this thread with arguments over rather or not sha1 or x y z hashing algorithm is secure or other offtopic banter.

[Arantor]

You actually need to do even more than just handle the places it's authenticated, since the password isn't even sent in plain text when logging in (which is levels of complication in itself to deal with, on TOP of the changes you're proposing)

Honestly, though, if you haven't made a decision as to what you're moving to, I would suggest you shouldn't be making such changes at this stage. Especially since 2.1 has already changed this to bcrypt, you may find the commits there useful (can't exactly look up the commits where this occurred right now though)

I honestly feel you're making this change out of a kneejerk reaction, though. Yes, hashes can be cracked - if the database is leaked. If you have the raw database at hand, assume it is compromised automatically. But unless you plan on leaking your database, why is this even a concern? Because if someone is trying to bruteforce it without happening to have the database, you're going to notice long before they actually succeed.

[MrStonedOne]

But unless you plan on leaking your database, why is this even a concern?

Because despite how much we security experts tell people not to reuse passwords, password reuse happens.

So I feel it is irresponsible to not assume every user is using the same password on my site as they are for their bank account, and act accordingly.

I also as a matter of principle assume a database leak will happen. It's better that way. (see: Avast)

IE: prepare for worst case, not best case.

[Arantor]

Of course password reuse happens. How does changing the password algorithm change this exactly? I'm assuming you're working off the policy that password reuse will be mitigated by way of a harder algo... but there's tradeoffs for this.

For example, I'm presuming you're going to be running SSL on the site? Because if not, you have bigger problems to contend with than changing the password algo - because if you change the password algo, you then have to mitigate sending the password in plaintext and given how terrible user security mindsets are, they're going to be sending passwords over unprotected wifi or other similar networks that can trivially scoop up the details.

No-one 'assumes' a leak will happen. Avast, as it happens, compounded their issues with a variety of other issues to the point where a database leak was pretty much inevitable since high value target + not taking proper care of their database/server = compromise waiting to happen. (And before we get into the 'how could you know that', I was one of the people who investigated what happened. I know exactly how they were compromised. And they were compromised without their database being leaked... the leak was the symptom, not the cause)

Honestly, weak/easily guessable passwords are so much more of a risk than a weak algo, and while I think it's laudable that you're being security-focused, I honestly think it's actually more effort than it's worth. Security is a journey of many parts - and the security needs to be on par with what you're protecting.

You cannot protect against users doing stupid things. Even now in 2014, 'password' is still amongst the top ten passwords. Along with such luminaries as '123456'. The reality is that no matter how strong you make the server side, the user is still easier to compromise, and spending the time hardening is unlikely to be that useful in practice.

[Kindred]

add to that -- as Arantor mentioned - 2.1 already uses a different structure...   so, if you change the structure in 2.0.x, you will be unable to upgrade to 2.1.x without redoing all your (unnecessary) work.

[MrStonedOne]

Yes, as it stands, SSL is forced on the webserver, all plaintext http queries are redirected and the referrer logged so any non-ssl internal links can be changed to use the SSL version.

Password simplicity isn't an issue, I'm not concerned with users getting their accounts on my site hacked all that could happen is some spammy posts get made, I'm concerned that if a user re-uses the secure password they were required to use for their email or bank, it should take more then 2 bucks worth of amazon ec2 time to crack it in the event my site's database gets leaks.

I've already worked out the logic i plan to use in a file I'll be calling passwords.php in sources.

It will handle password hashing, checking, and notifying the calling function if the password needs to be rehashed and updated because it uses an older hashing algo, I've already started writing this file.

As for the js thingy, ya I plan on fully scrapping that.

I already have to do a lot of customization to the site, there really is no sense to not upgrade the password security to something that a 16 year old kid working 5 hours a week at a fast food chain couldn't afford to break while I'm at it.

There is also the fact that the people involved in the site above me have already said that a hashing algorithm update will be required if I want the sites dns to continue to point to my server.

This is happening, one way or another, I was hoping I could get pointed in the right direction without having an derailing argument over rather or not password storing security is my responsibility.

add to that -- as Arantor mentioned - 2.1 already uses a different structure...   so, if you change the structure in 2.0.x, you will be unable to upgrade to 2.1.x without redoing all your (unnecessary) work.

You have no idea how much customization I'm already going to have to do. So that ship has already sailed.

[margarett]

You need to perform a search by content for sha1. That will give you all places it's used... Depending on the context, your script might need to behave differently.
Some places, though, don't relate to members authentication (eg, there is a call in Subs.php for attachments hash, you don't need to change that), you don't need to worry with Subs-Compat.php, etc.

[Arantor]

Except we have a responsibility of care to you to advise you on proper course of action.

[live627]

https://github.com/SimpleMachines/SMF2.1/pull/1674/files (relevant changes discussed above)

Good luck. You're on your own.

[Arantor]

And before there is any question as to "why is SHA 512 mentioned", Bcrypt is used for the server side storage, SHA512 is used in relation to the token issued, which is not the raw password at this point in time...