Somehow it seems people think they are more secure by using SHA1 hashes instead of the default MD5 for the passwords.

Now someone created PHP files to create SHA1 hashes and released that into phpnuke 7.1
That is a bit bloated and a bloat to the system.

Ofcourse the CPG-Nuke people know better ways like using PHP 4.3.x
PHP 4.3.x already has SHA1 encoding build in so why use bloated material ?

Now there's 2 problems:
- current passwords
- lacking servers that didn't upgrade their PHP versions

There are 2 ways to solve the passwords problem:
- sha1() the md5 strings
- create new password for each user in sha1() and email that to everyone

There are 2 ways to solve the PHP version problem:
- force servers to upgrade their software or move to a better host
- let the system autodetect PHP version and switch md5/sha1

Benefit of sha1:
- stronger encryption
- takes longer to decrypt for hackers

So i was thinking of doing sha1() over the md5 if version is 4.3.x like this

PHP:

$pass = md5($password); if ( function_exists('sha1') ) $pass = sha1($pass);

Also there are mor features like mhash or sha1lib

PHP:

But those will only work if the libraries are installed: mhash.sourceforge.net/

So should we implement this or not ?

DJMaze wrote:

Now someone created PHP files to create SHA1 hashes and released that into phpnuke 7.1 That is a bit stupid and a bloat to the system.

What else is new?

DJMaze wrote:

There are 2 ways to solve the passwords problem: #1 - sha1() the md5 strings #2 - create new password for each user in sha1() and email that to everyone

#1 =
#2 =

DJMaze wrote:

There are 2 ways to solve the PHP version problem: #1 - force servers to upgrade their software or move to a better host #2 - let the system autodetect PHP version and switch md5/sha1

#1 =
#2 =

DJMaze wrote:

So should we implement this or not ?

It definitely sounds do-able. I'd do it.

It'd be my preference that MD5 / SHA1 hashes be configurable. Otherwise you have the person who's shared host upgrades their PHP overnight getting screwed.

If it's configurable (one way, of course)... It's up to the admin to decide when is the best time to switch over if they are upgrading.

...

I think autodetection is the key, many people won't even know the difference between one or the other (like me lol) Unfortunately most things need to be 'dumbed-down' or automated so the unknowing user can still use it.

Hmm what about a button

On clean install it asks if you want to use stronger password encryption or not.
And a warning that when you switch hosts they have to run atleast PHP 4.3.0

In admin main_settings a button that converts all passwords if you want to switch.

Ofcourse the "feature" will only be shown if the function exists.

And if you use the stronger encryption we hardcode the setting so you can't switch back.
Ofcourse when you manualy modify the hardcode setting a backup check is done on admin login to check if you messed with it.

sounds just about right Maze

How do you propose:

Quote::

DJMaze wrote: #1 - sha1() the md5 strings

I've never heard of sh1. Offshoot of md5?

Boath encodings are bad.

MD5 is hacked in a 5 minutes if is already in MD5 database. Otherway good hecker need about and hour to find a code. So MD5 is not good. Think about if MS will use MD5 for their security codes. BIG DISASTER

A. Victor is correct that neither are terribly effective in today's computing environments.

B. But this is the issue, neither are encryption solutions on their own, they are simply hashing methods.

C. Regardless of the cracking ability of todays md5 crackers (of which an entire culture has formed around) neither is required to be 'secure' in the real world, or in many (or should be many) 'good' applications in the market. This thread was a discussion ages ago about whether one should use one over the other and most perceived benefits where not substantial.

Epilogue. I think that using multiple hashing methods can improve the randomness.

Old thread, but new user, so I didn't see this when it was active.

MD5 is getting less and less secure. Professor Wang in China and her team succeeded in finding collisions algorithmically (previously people only found pseudo-collisions or they foudn collisions via brute force).

This means that, whether in a lookup table or not, her team can find a collision of an arbitrary MD5 hash in under an hour.

They achived similar results with SHA-1.

I agree that these hashes are not real security. I'm brand new to the Nuke world, but I would guess that most Nuke users are sending logins in plain text anyway with no SSL layer, so you're not typically talking about highly secure systems. If you have high-value data and you're already using SSL and are still dependent on MD5 or SHA-1 for signatures, though, it seems like there is a notable and increasing risk.

Anyway, there's some good reading on the Wang results at the following pages:

The relatively hardcore version (beyond me): eprint.iacr.org/2004/199.pdf

The version for regular folks: www.pgp.com/library/ct...ashes.html

Related news story:
www.pgp.com/news/sha1.html

Bringing this back up.

Just wondering on what the current thoughts are from switching from MD5.

With the current trend of creating MD5 Hash databases and brute force scripts that are run on nice powerful servers the threat is just increasing. I just got through reading through a site that has over 12,408,249 unique Hashes to compare against. Mainly all words, and noun type objects. Also recently was on a site that claimed that a 8 character alpha-num password could be brute forced in under 30 minutes.

In my opinion this is due to the popularity of using MD5 across the PHP programming board. All technical issues aside, just by using SHA1() we would eliminate this popularity effect and increase the security even more. MD5 will continue to be i the public eye until the server hardware is there to brute force passwords in seconds. All it takes is some one with more resources than time. At that point anything hashed through MD5 will be deemed unsecure and we will HAVE to do something then.

There are several workarounds and things people do to beef up the MD5 hashes such as adding salts or adding random characters to the MD5 hash that is stored and then removing them throgh the script, but nonw of these will work as long as the project has the source available for people to view.

Just looking for thoughts on this because at some point DragonFly will have to address this issue.

OK, really we're approaching Halloween and all, but necro-posting to a cryptography thread... =/

tank wrote:

Bringing this back up. Just wondering on what the current thoughts are from switching from MD5.

Arise thread, and LIVE! No, not really. This thread died a natural death a while ago, for a number of really good reasons, not just old age.

tank wrote:

With the current trend of creating MD5 Hash databases and brute force scripts that are run on nice powerful servers the threat is just increasing. I just got through reading through a site that has over 12,408,249 unique Hashes to compare against. Mainly all words, and noun type objects. Also recently was on a site that claimed that a 8 character alpha-num password could be brute forced in under 30 minutes.

All cryptographic hashes, now, and in the future, are vulnerable to dictionary attacks. Increasing computing power and the size (and cost) of massive storage decreasing, it's now feasible to precompute large (if not comprehensive) dictionaries. In which case you just find the cyphertext and look up the plaintext, takes no time at all. This is just as true of MD5 as SHA-1. Which is why such algorithms are generally used with a [url=http://en.wikipedia.org/wiki/Salt_(cryptography)]salt[/url] to extend the seach space.

tank wrote:

In my opinion this is due to the popularity of using MD5 across the PHP programming board. All technical issues aside, just by using SHA1() we would eliminate this popularity effect and increase the security even more.

You are not only advocating security by obscurity, which is a FALSE premise to begin with. SHA-1 is a technical revision of SHA (FIPS 180), and it has seen heavy use in the U.S. Federal Government, as well as in commercial applications. It is not obscure or less popular by any means!

You also glossed over rick_deckard's reply just prior to yours, where he mentions the research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have "broken" the SHA-1 algorithm. This is not an esoteric hypothetical attack with a very narrow applicability, it's a serious break in the algorithm. If you believe that MD5 is worthless as a protective measure (it is not) replacing it with one with an acknowledged serious flaw is extremely poor logic, especially if you reason that the popularity of the algorithm is its primary protective value!

tank wrote:

There are several workarounds and things people do to beef up the MD5 hashes such as adding salts or adding random characters to the MD5 hash that is stored and then removing them throgh the script, but nonw of these will work as long as the project has the source available for people to view.

/sigh OK, you're way off now... You can design a perfectly feasible and secure system with public source and/or algorithms. The SSL protocol, and indeed the very SSL implementation (OpenSSL) used by just about everyone is open-source. Same for ssh. The Advanced Encryption Standard (AES), the topic of FIPS-197, again a U.S. gov't standard encryption algorithm, is also public (it was in fact, selected as part of a public review process).

You can add salt to the system. Wouldn't be that bad of an idea either, except there's no way to do it without having each and every user on the system reset their password in order to do it. And the process and mechanism for doing that is fought with opportunity for chaos and fraud itself.

Adding salt is useless only if everyone uses the same salt value. Whether the implementation is known or not makes no difference. In fact, if any cryptographic system requires the algorithm remain secret, it fails any reasonable test of reliability. That is why "security by obscurity" is never acceptable.

tank wrote:

Just looking for thoughts on this because at some point DragonFly will have to address this issue.

Why does it have to address this? Where is your risk analysis? What is the threat profile? There just is no compelling argument for it.

You need to have the password hashes to begin with, and if someone has free and clear access to you Dragonfly database tables, you've got security problems that have nothing to do with Dragonfly. You can't perform a dictionary attack without the password hash.

PGP trying to create stronger SHA-1 but it not going to last forever. In Future, Chinese might break PGP SHA-1 then nothing is secure.

darkgrue wrote:

All cryptographic hashes, now, and in the future, are vulnerable to dictionary attacks. Increasing computing power and the size (and cost) of massive storage decreasing, it's now feasible to precompute large (if not comprehensive) dictionaries. In which case you just find the cyphertext and look up the plaintext, takes no time at all. This is just as true of MD5 as SHA-1. Which is why such algorithms are generally used with a [url=http://en.wikipedia.org/wiki/Salt_(cryptography)]salt[/url] to extend the seach space. You are not only advocating security by obscurity, which is a FALSE premise to begin with. SHA-1 is a technical revision of SHA (FIPS 180), and it has seen heavy use in the U.S. Federal Government, as well as in commercial applications. It is not obscure or less popular by any means!

You can call it whatever you want but the reality is sites that are popping up in non-hacker community have been increasing at a rate that will eventually spark a bandwagon effect and we'll have more and more people adding resource for the MD5 defeat. I know that all hashes are subseptible to brute force and dictionary attacks. But when the vast majority of the internet public is focusing on MD5 it stand to reason that it needs to be a topic of concern.

darkgrue wrote:

You also glossed over rick_deckard's reply just prior to yours, where he mentions the research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have "broken" the SHA-1 algorithm. This is not an esoteric hypothetical attack with a very narrow applicability, it's a serious break in the algorithm. If you believe that MD5 is worthless as a protective measure (it is not) replacing it with one with an acknowledged serious flaw is extremely poor logic, especially if you reason that the popularity of the algorithm is its primary protective value!

I actually did gloss over that. And perhaps that is the reason for holding off changing. It would be an acceptable answer to me. I realize that alternative methods aren't always better. But I at least like to know that it's being given attention.

darkgrue wrote:

/sigh OK, you're way off now... You can design a perfectly feasible and secure system with public source and/or algorithms. The SSL protocol, and indeed the very SSL implementation (OpenSSL) used by just about everyone is open-source. Same for ssh. The Advanced Encryption Standard (AES), the topic of FIPS-197, again a U.S. gov't standard encryption algorithm, is also public (it was in fact, selected as part of a public review process).

This is irrelevant to the topic. I didn't say open source was unsecure. I said publicly viewed code (salt values) is worthless to security becuase anyone can view the salt and also how it is used.

darkgrue wrote:

You can add salt to the system. Wouldn't be that bad of an idea either, except there's no way to do it without having each and every user on the system reset their password in order to do it. And the process and mechanism for doing that is fought with opportunity for chaos and fraud itself.

True

darkgrue wrote:

Adding salt is useless only if everyone uses the same salt value. Whether the implementation is known or not makes no difference. In fact, if any cryptographic system requires the algorithm remain secret, it fails any reasonable test of reliability. That is why "security by obscurity" is never acceptable.

Exactly what I said above

darkgrue wrote:

Why does it have to address this? Where is your risk analysis? What is the threat profile? There just is no compelling argument for it. You need to have the password hashes to begin with, and if someone has free and clear access to you Dragonfly database tables, you've got security problems that have nothing to do with Dragonfly. You can't perform a dictionary attack without the password hash.

Then why have any hash at all with that thinking? That's just silly. WE ar talking about hashing Passwords not system security. There are a few ways people can get the hash out side of system penetratrion. Cookies left on Public Access computer comes to mind. True.. that is the users stupidity but it can and does happen.

As to my risk analysis. This is not the forum for formalities like that. My risk analysis is just what I posted. DragonFly uses MD5 and no salt or any other method to obscure the hash and I just vistied two popular sites (one that was featured on Slashdot) that specialize in throwing hardware at brute forcing the MD5 hash specifically. I have yet to see a popular site that does that for SHA1. They are out there I'm sure. But MD5 seem to be the Hash in the spotlight and I don't forsee it going away.

The MD5 is used serverside so they need to break in first to get the hash.
Since they already broke in, they don't need the hash (after all they are already there)

Passwords are hashed to provide some sort of protection to your members in case someone brakes in. This because humans use one password for everything, so when someone downloads all your members he can login anywhere.

I have also one password but if someone hacks a website i'm member of (like getfirefox.com which was one of the last), he can only spam websites i'm member of because all my important things always have a unique password and none the same.

If everyone used unique passwords on each website we don't need hashing at all.