"Seeding"

When coding user based systems, do you use "seeding" i think thats the term, for example where you add a key onto their final password, to make the whole more protected?

I personally "hash" my password, which I think is the word you're listening to

Originally Posted by GarethP I personally "hash" my password, which I think is the word you're listening to

Haha, no. Its an add on to password security, jelsoft use it with their vbulletin service
I didnt really explain it well though!

I think you're looking for salt rather than seeds

Using a salt for encryption is nice and all, but completely pointless if the server becomes compromised. Most people opt for md5 hashing passwords, which although not hugely secure, works to keep prying eyes from seeing passwords in plain text.

Originally Posted by JulesR Using a salt for encryption is nice and all, but completely pointless if the server becomes compromised. Most people opt for md5 hashing passwords, which although not hugely secure, works to keep prying eyes from seeing passwords in plain text.

Thats the name salting, bah, how did i manage to get the names confused ¬_¬, Im just wondering whether or not I should start using this method in future work.

Originally Posted by iwearoddsocks Thats the name salting, bah, how did i manage to get the names confused ¬_¬, Im just wondering whether or not I should start using this method in future work.

It honestly can't hurt to salt your passwords when encrypting them, and it's probably a good practice to get into, but fundamentally you need to understand when/where it's important and how it differs to other forms of obfuscation.

If security isn't a huge concern of yours, and you just want to stop prying eyes from seeing the unencrypted and plain text password field, then md5 hashing is considered adequate. The downside is that it's not hugely secure. Because md5 hashes always match the source string, it's possible to build what are known as rainbow tables to almost reverse-hash an md5 string and determine the source string used. For example, md5 hashing the word "password" will ALWAYS result in the resulting md5 string of 5f4dcc3b5aa765d61d8327deb882cf99. If an attacker were to build a database of md5 strings based on common dictionary words, they'd be able to crack the password with relative ease by searching for this hash. Still, it's far better than leaving the password in plain text, and should be the bare minimum when dealing with any passwords at all.

Using a specified salt for password encryption adds a slightly thinner layer of defense on top of md5. Now if an attacker obtains the encrypted string, instead of just being able to generated a list of encrypted strings to compare your string to like they could with md5, they would also need to discover the 'salt' that was used to encrypt it to begin with. Obviously if you use the same salt every time you encrypt a password it makes it even easier for them to crack. Unfortunately, you're almost forced to use defined salts, because without them the resulting encrypted string is practically useless. If you're doing things like user authentication, you HAVE to use a defined salt, there's not really any other way.

The biggest problem with using defined salts is that the salt must be stored somewhere - and it's usually in a file. If an attacker obtains access to these files, your passwords are as good as stored in plain text anyway. Obviously md5 hashing doesn't suffer from this problem, providing the source string is random enough that the resulting hash isn't something searchable as in the above example.

Sorry for the rant, but hopefully someone's learnt something

Woah, lengthy post, thanks

But if you had a unique salt per user for example based on their id and credentials then the md5 hash would become almost uncrackable right? even if the hacker had the files as you cant decode an md5 hash and a database would not have a match for it, plus it adds safety if your using cookies

Just my views, what do you think about it?

Originally Posted by iwearoddsocks Woah, lengthy post, thanks But if you had a unique salt per user for example based on their id and credentials then the md5 hash would become almost uncrackable right? even if the hacker had the files as you cant decode an md5 hash and a database would not have a match for it, plus it adds safety if your using cookies Just my views, what do you think about it?

Nice idea, but it's the same situation. To generate your custom encrypted string, you'd need to code your registration system files to use their id and credentials. If an attacker got access to these files, they'd see the method you used and it'd only be a matter of time...

Obviously that's a hypothetical scenario, and depends hugely upon someone getting access to those files. I guess it just depends how paranoid you want to be Doing it via your method is certainly more secure than md5 hashing from a database perspective, anyway.

I'd disagree on the hacker thing because even if the hacker did have access to the database, and the like decoding method he still wouldnt be able to decode and md5

uniquekey-password
say unique key is like
%324092039"$$%%
and the password is password
then you md5 that, im sure he/she would not be able to like match that to an existing, if were talking about using this to protect users security but the site should be secure too so we dont have to take these methods ^_^