Jump to content

IP.Board password hashing is no longer secure


Ryan H.

Recommended Posts

I am thinking like the way we encrypt the password with keyword, each installation having 1 keyword that encrypted with the domain, let say sha-1 encrypted domain and with that keyword we encrypted the password.

So that possibilities hackers knowing that encrypted domain are 10% :D

just my fifty cents..

Link to comment
Share on other sites

  • Replies 53
  • Created
  • Last Reply

I long for the day when we don't have to use passwords anymore, bring on biometrics. I have to keep a spreadsheet of all of my passwords, since so many sites have different rules about them, which sucks from a security standpoint.




Been using it for years. Great chrome plugin. (one for FF is decent too)
https://agilebits.com/onepassword

Allows for backing up to a thumb drive aswell.
Link to comment
Share on other sites


I long for the day when we don't have to use passwords anymore, bring on biometrics. I have to keep a spreadsheet of all of my passwords, since so many sites have different rules about them, which sucks from a security standpoint.




No thanks. Flaws in other people's hardware become your problems. I can change my password and complexity at will and have a different one for each web site (and really, with free software like PasswordSafe, why not?) I can't change my thumbprint for each web site.
Link to comment
Share on other sites

  • 4 months later...

Nothing you can do against bruteforcing? Ever heard of using a hashing algorithm that isn't fast as balls?

MD5 is not the way passwords should be hashed these days. Look up bcrypt or something else that can't easily be bruteforced. It's not possible to stop someone from bruteforcing sure, but when you use a hashing algorithm that can be computed hundreds of millions of times per second you are doing something wrong... There ARE alternatives.

I do hope I'm behind the times and that IPS doesn't still use MD5 but can't be assed to actually read around the site. So does this mean the account I'm using right now someone may have the hash/salt combo somewhere?

Using strong passwords will help - they likely try common passwords first when doing a bruteforce attack on someone. Though not all blame is on the user, here.

Link to comment
Share on other sites

For a banking/government based site, enforcing secure passwords and requiring you to make changes to your password every XX days is reasonable. The latter being more so for government based services.

But for a generic forum, not really. It's just a forum.

I admittedly have about 4 different common passwords of various strengths that I use for misc. sites, such as this one.

Honestly though, it's not difficult to create a secure password that's over 15 characters in length. Mix in a favorite music lyric with a favorite quote, favorite catch phrase, whatever. Add capitalization, use numbers in place of letters.. so on. Secure and still easy to remember. It's more secure than the impossible to remember "aZ#%Ji3Pw0R2" password.

It's not terrible practice to write a new password down somewhere and stick it in your wallet for a bit until you're sure you've memorized the password either, afterwards just ripping it up and flushing it down the toilet or burning it.. or just throwing it in the trash like most normal people do.

Link to comment
Share on other sites


For a banking/government based site, enforcing secure passwords and requiring you to make changes to your password every XX days is reasonable. The latter being more so for government based services.



But for a generic forum, not really. It's just a forum.



I admittedly have about 4 different common passwords of various strengths that I use for misc. sites, such as this one.



Honestly though, it's not difficult to create a secure password that's over 15 characters in length. Mix in a favorite music lyric with a favorite quote, favorite catch phrase, whatever. Add capitalization, use numbers in place of letters.. so on. Secure and still easy to remember. It's more secure than the impossible to remember "aZ#%Ji3Pw0R2" password.



It's not terrible practice to write a new password down somewhere and stick it in your wallet for a bit until you're sure you've memorized the password either, afterwards just ripping it up and flushing it down the toilet or burning it.. or just throwing it in the trash like most normal people do.




The length and obscurity of a user's password is much less of an issue when the hashing algorithm is much slower to compute. Generally it's not us, who have good passwords that are having their passwords decrypted after a security breach, it's the users. While it might be their own fault for not using a secure enough password, why not help things anyway by having a more secure hash?
Link to comment
Share on other sites


The length and obscurity of a user's password is much less of an issue when the hashing algorithm is much slower to compute. Generally it's not us, who have good passwords that are having their passwords decrypted after a security breach, it's the users. While it might be their own fault for not using a secure enough password, why not help things anyway by having a more secure hash?



Oh, of course. Having a good hash is always good. It's amazing how many large corporations tend to store sensitive data like passwords in plaintext, really.
Link to comment
Share on other sites

Oh, of course. Having a good hash is always good. It's amazing how many large corporations tend to store sensitive data like passwords in plaintext, really.


Disney not only stores passwords in plaintext, but it's also case insensitive. So if your password is "PassWord", then you could type it in as "PASSWORD" or "password" etc.

A lot of sites place restrictions on passwords, but not to make someone use a more secure password, rather it restricts the complexity of the password. For example, some sites limit you to using letters (upper/lower), numbers and a very limited range of 'other' characters. So if you normally use a password like "Password#123", it will reject it with an error telling you that you can only use letters, numbers and something like _ or - or something else. I consider that a HUGE gap in security because suddenly, brute force cracking becomes easier if the 'hashed' passwords are ever obtained somehow (that's IF the passwords are even hashed). It makes me wonder if the developers of those sites didn't get messed up in the head and somehow believe that limiting the characters somehow makes passwords more secure. Sites like that actually make me cringe because it's a disaster waiting to happen.
Link to comment
Share on other sites


I consider that a HUGE gap in security because suddenly, brute force cracking becomes easier if the 'hashed' passwords are ever obtained somehow (that's IF the passwords are even hashed). It makes me wonder if the developers of those sites didn't get messed up in the head and somehow believe that limiting the characters somehow makes passwords more secure. Sites like that actually make me cringe because it's a disaster waiting to happen.




I agree, all of my passwords contain a mix of numbers, letters and symbols and it really annoys me when a site doesn't allow you to use them. What *is* the point?

I consider it a huge fail on the part of a website if I ever request my password from them and I get an e-mail with it in plaintext.
Link to comment
Share on other sites


MD5 is still being used for IP.Board. But yes, a slower hashing algorithm would be great, it should even be possible to convert these on the fly as users successfully login to their accounts.



Right, so could we get any feedback from Invision about their plans?
Link to comment
Share on other sites

Right, so could we get any feedback from Invision about their plans?


There are a couple of things to keep in mind.

1. Any hashing method used has to be supported by all (or nearly all) hosting environments. md5 is one of those methods.

2. You might be tempted to say, "So use md5 as a backup but use something else if it's available." but there's a catch-22 to that. Let's say someone is on a host that supports an alternative method and so that method is used. Then they move to another host that doesn't support it. All of a sudden, EVERYONE has to reset their password in order to be able to sign in. So then it's, "Okay so if you use the better method but also store it using the backup method in case that happens." but then that in itself would defeat the purpose.

It still comes down to a simple fact that no matter the method used, if someone obtains all pieces of information necessary to crack a password, then it can be cracked, period. Stronger methods may take longer, but it can still be done. Things that may seem impossible now could be much easier in just a couple of years. Saying "if people use passwords that are 14 or more characters will make it impossible" isn't really true because it's still possible just with today's technology, it's not very likely unless a hacker has access to several high-end machines & GPU's and has a way of efficiently delegating out the task to those machines. Within a couple of years, it may be possible to hash 10 times what can be done now, making 14 character passwords somewhat 'easy'.

There are very few ideas that would make having the hashes useless and one way is to somehow withhold a key element from the equation. In another topic, I suggested the idea of having an optional 'code' for members to use. The code wouldn't be stored in the database and without that code, the end result would be much harder to achieve. Some tell me that it'd just be easier/better to use a longer password, but the problem with that is that the advice only works when people use longer passwords to begin with. If they use a simple password and aren't likely to change that, then the best option is to give them a way to use a secondary 'password' (software could make sure they aren't the same thing) and add that into the equation. Suddenly, instead of one unknown, there are two unknowns and more processing has to be done to take the additional unknown into the equation.

That's just one concept that could improve the level of security with the hashes. There are others, but keep in mind that anything that is always accessible to the site will also be accessible to the hacker (if they manage to compromise your site that is). Doesn't matter if it's 'hidden' in a file or 'hidden' within the database, if the hacker knows what to look for, they can find ways to get it once they're in.
Link to comment
Share on other sites


There are a couple of things to keep in mind...



And if you really wanted to be more secure, I'm sure you could modify the hashing algorithm yourself. Maybe not through hooks or mods and you'd have to keep the file updated throughout version changes.. but I think it'd be possible.

If you're really concerned about these technicalities, I'd think that making a few code changes shouldn't be too huge a task.

At least in this case, you're acknowledging the points stated here and are choosing to use your own method despite the possible drawbacks.
Link to comment
Share on other sites

And if you really wanted to be more secure, I'm sure you could modify the hashing algorithm yourself. Maybe not through hooks or mods and you'd have to keep the file updated throughout version changes.. but I think it'd be possible.



If you're really concerned about these technicalities, I'd think that making a few code changes shouldn't be too huge a task.



At least in this case, you're acknowledging the points stated here and are choosing to use your own method despite the possible drawbacks.

I think you misunderstood.

I'm using what IPS is supplying. The reason is for reliability and security. How reliable or secure would it be for me to make an edit, later on upgrade to a newer version, have to make the change again (if I remember) and at some point, run the risk of my edits being wrong and causing a massive bug that opens the door for hackers? Thanks but no thanks.

I agree that there are ways to improve security, but those ways have to work on all (or almost all) installs. For those that it wouldn't work on, a function to produce the same results, even if it might be a small (microsecond) longer. In short, something that would work for all sites. Let's take sha512 as a hashing method. hash() is available for PHP 5.1.2 and up, and using that takes longer than md5. So that means that someone trying to brute force the password would get slower results. Sounds all great right? But what about a site that has a large number of users signing up or signing on each day? That could potentially cause issues. Not saying it will, but it could. There could be other drawbacks as well. Let's say that overall, it's 'perfect' and so it should be used. Doesn't change the fact that if someone gets the salt and hash, they could crack the password. Might take them a little bit longer, but it could still be done. That would be like putting a small bandaid on cut that requires stitches. The thing about it is that it's not a flaw with how IPS is handling it, it's a flaw no matter where you go. One way hashes can be cracked when the formula is known. It's just how it is.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...