How does VBulletin or Paypal store their passwords? Can you tell me in a way that I can copy? :P

__________________
Signatures are nothing but incriminating.

Passwords for what? They store the database passwords in a file and most of the others in the database. I've never seen paypal's source, so I dont know what they do.

__________________

like, database passwords.

does vb like... do salt first, or even use a salt? do they combine md5 with sha1 or do they use one or the other?

__________________
Signatures are nothing but incriminating.

No, VB has their DB password in a PHP file, completely unencrypted.

__________________

and yet, that's one of the great forum softwares. ;P i dunno

__________________
VillageIdiot can have my babbies ;d

My bet is that Paypal uses an encryption for their data and not Hash and salt.
Can be wrong, but i don't think that a site as Paypal can't afford not to be as safe as possible.

What do you mean? It is not a security risk to have it in the PHP file. Its not like anyone can view the source.

__________________

well yes but. nevermind

__________________
VillageIdiot can have my babbies ;d

I mean like the database password for users. Do they shai($username . $salt) or what?

__________________
Signatures are nothing but incriminating.

Users dont have database passwords.... If what you mean is their login passwords, they are encrypted, I think via sha1.

__________________

just sha1, or do they use a salt? Is the salt before or after the password? :/

__________________
Signatures are nothing but incriminating.

I dont know. Sha1 is sufficient, it is a destructive algorithm. There are rumors that it has been cracked by a group of Chinese hackers, but I'm not sure I believe it.

__________________

VB does
Weird... Why use that?

__________________
Signatures are nothing but incriminating.

There's way better encryption than MD5 and SHA1, and if it was needed could easily be implemented, but for one problem. At least in this country, which like it or not has a heavy hand when leaning on other countries to do the same - the government doesn't want the public to have stronger encryption, because then they risk the possibility that they won't be able to crack civilian communications when ever necessary. </today's fun little conspiracy factoid>
-m

that's nothing, I use zlib compression, and the hash function which allows sha256, and many more, I also use substring, and more.

__________________
VillageIdiot can have my babbies ;d

The reason they use something like that is first there something called rainbow tables or glorified brute forces that try and guess your password, add a salt and it gets that much harder but they can add the salt to the list and have them md5 that now md5 the password then salt it and md5 it and it just's that much harder to crack...

In the end MD5 and SHA1 have been cracked because computers can't do true random numbers (they're based off algoritms like the twister) and thus reversible. so if a team of determined hackers want your password than they will get them, the only true way to be secure from network intrusion is to black box it - I find security to be more a game of "Tire out the hacker" then "Keep the hacker out" (I refrain from using "he" or "him" because some girls are very nasty hackers..)

__________________
"What everyone seems to forget is that while knowledge certainly is something - it's the implementation of knowledge that brings power" - Andres Galindo.

Rainbow tables are only good if you already know the password.

__________________
VillageIdiot can have my babbies ;d

MD5 was cracked a while ago, there are only rumors of sha1 being cracked. Sha1 nor MD5 use random algorithms because they must come out with the same result every time. They destroy the original value, meaning that even if you can reverse the process, there are unlimited possibilities of what it could be. If you dont have a short or dictionary word password, the hacker wont know one from another. Using two or more wont render much since anyone experienced enough to crack it once would catch on to what it was and just do the process again.

__________________

For my projects I use a combination of 2 salts (1 Static, 1 Dynamic). When a user registers to my website the backend will generate a random salt key for each user. Even if 2 different users register to my website with the same password, the resulting hash will be different.

So if the database was ever hacked or stolen, they would be missing the static salt key, thus it would prove to be impossible for them to bruteforce any of the passwords.

However I'll touch wood, just incase.

1 dynamic? How do you go about that, if I may ask? As far as I understand you need the same SALT to unhash as you use in the hash, so don't you have to store the dynamic one somewhere?
-m