|
|
|
|
|
|
|
|
|
Thread tools
Search this thread
Display Modes
|
|
09-02-2008, 05:41 PM
|
#1
|
Status: Junior Member
Join date: Mar 2008
Location:
Expertise:
Software:
Posts: 91
|
"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?
|
|
09-02-2008, 06:26 PM
|
#2
|
Status: Request a custom title
Join date: Apr 2007
Location: UK
Expertise: Code & Programming
Software: Coda, TextMate, Sublime 2
Posts: 2,097
|
I personally "hash" my password, which I think is the word you're listening to
|
|
09-02-2008, 11:29 PM
|
#3
|
Status: Junior Member
Join date: Mar 2008
Location:
Expertise:
Software:
Posts: 91
|
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!
|
|
09-03-2008, 12:10 AM
|
#4
|
Status: Superstar
Join date: Apr 2005
Location:
Expertise:
Software:
Posts: 4,449
|
I think you're looking for salt rather than seeds
|
|
09-08-2008, 09:08 PM
|
#5
|
Status: Request a custom title
Join date: Apr 2007
Location: UK
Expertise: Code & Programming
Software: Coda, TextMate, Sublime 2
Posts: 2,097
|
Originally Posted by Jeff Andersen
I think you're looking for salt rather than seeds
|
Ah, misread the original poster's post. This is what I meant
|
|
09-03-2008, 03:42 AM
|
#6
|
Status: Member
Join date: Apr 2008
Location:
Expertise:
Software:
Posts: 129
|
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.
|
|
09-03-2008, 03:59 AM
|
#7
|
Status: Junior Member
Join date: Mar 2008
Location:
Expertise:
Software:
Posts: 91
|
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.
|
|
09-03-2008, 04:36 AM
|
#8
|
Status: Member
Join date: Apr 2008
Location:
Expertise:
Software:
Posts: 129
|
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
|
|
09-03-2008, 06:14 AM
|
#9
|
Status: Junior Member
Join date: Mar 2008
Location:
Expertise:
Software:
Posts: 91
|
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?
|
|
09-03-2008, 03:13 PM
|
#10
|
Status: Member
Join date: Apr 2008
Location:
Expertise:
Software:
Posts: 129
|
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.
|
|
|
|
|
|
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
|
|