I agree with all statements said, but I must say even making the hacker figure out which encryption method would only hold off a hacker for so long as they would take some time to crack the first one then it would be fairly easy to crack the rest.
Incorrect, that is what a salt is for. If simply the plaintext password is what is hashed and stored in a password database of 5000 users, then after I have brute forced all possible eight-character-long password hashes, any user accounts that used a password that length or less have been cracked - anything from "myLogin1" to "G0odPW69" have been found if any user has used a password that length or shorter. However, if the plaintext password plus some extra data (salt) that is unique per-user (and even mildly complex) is hashed to create the stored password hash, this means I have to brute force the password space for every user account individually, since there is no correlation between the hashes of users. Instead of being able to quickly find the weakest passwords in a database of 5000, I would now have to brute force crack every account. 
Topic: Info about the recent attack - page 2. (Read 52527 times)
I agree with all statements said, but I must say even making the hacker figure out which encryption method would only hold off a hacker for so long as they would take some time to crack the first one then it would be fairly easy to crack the rest.
[being sarcsum]
Maybe we should just all get DNA-keys and we prick blood on a test strip and then we log in with our DNA no hashing algorithm needed.
[/end sarcasum]
[being sarcsum]
Maybe we should just all get DNA-keys and we prick blood on a test strip and then we log in with our DNA no hashing algorithm needed.
[/end sarcasum]
For the record, this is the security through obscurity:
Salts are designed to defeat precomputed rainbow tables that may exist for many common hash functions. With a sufficiently long per-user salt, the time/memory trade-off rainbow tables provide no longer helps. The salt doesn't even have to be that "random" for that task (though I think the entropy should be comparable to password entropy).
But what resembles to be the best solution on this on-demand generated salt with Open Source software would be to create a salt class with different approaches and let the site owner to select which to use within config. This way an attacker would have to guess first which salting method was used before attempt to attack, and within the availabilities to generate the salt and input; xored strings, substring of hashes, multiple round sha hashing, bitwise etc... this would may means he would grow old before achieve something, even to the weakest of passwords.
Salts are designed to defeat precomputed rainbow tables that may exist for many common hash functions. With a sufficiently long per-user salt, the time/memory trade-off rainbow tables provide no longer helps. The salt doesn't even have to be that "random" for that task (though I think the entropy should be comparable to password entropy).
That's security by diversity, there's no obscurity as the attacker can still access the code of the class, what he can not know before hand is what function is being active without the config file.
It's quite the same of what you do with hashing, imagine if single hashing algorithm is used web-wide, this would be a leverage to a potential attacker, a single RT would be enough for all unsalted hashes and by now probably even 50 chars long pwds would be there.
EDIT: Thinking it over, this system have a big flaw, an attacker could register himself and by knowing how salt is generated would get the function quite easily- but this would be what some of you "obscurity bashers smart arses" should come with instead of pre-made sentences you barely know the meaning.
For the record, this is the security through obscurity:
Salts are designed to defeat precomputed rainbow tables that may exist for many common hash functions. With a sufficiently long per-user salt, the time/memory trade-off rainbow tables provide no longer helps. The salt doesn't even have to be that "random" for that task (though I think the entropy should be comparable to password entropy).
But what resembles to be the best solution on this on-demand generated salt with Open Source software would be to create a salt class with different approaches and let the site owner to select which to use within config. This way an attacker would have to guess first which salting method was used before attempt to attack, and within the availabilities to generate the salt and input; xored strings, substring of hashes, multiple round sha hashing, bitwise etc... this would may means he would grow old before achieve something, even to the weakest of passwords.
Salts are designed to defeat precomputed rainbow tables that may exist for many common hash functions. With a sufficiently long per-user salt, the time/memory trade-off rainbow tables provide no longer helps. The salt doesn't even have to be that "random" for that task (though I think the entropy should be comparable to password entropy).
Isn't it funny that besides your self-claims I was the only one actually posting some lines of code showing some implementation and let someone try out to see how it would look, render, resources usage and so on?
From your kind I've "theories" and self-proclamation BS.
From your kind I've "theories" and self-proclamation BS.
Let me guess, by microcontroller I must assume some Java PIC, by your posts I *REALLY* doubt you would touch ASM even with a 10 feet pole.
I'm 40 years old and wrote my first assembler program when I was 12a. You might want to let this one go, any basic level crypto 101 course will tell you the same things I've posted since they're considered to be common knowledge if you design and implement something with provable security.
"an attacker would have to guess first which salting method was used" is what disqualifies you outright in this argument btw
(I'm leaving this discussion here since I don't think it produces anything of value to theymos and the reasons he had when creating the thread)
a: Since, umm, that's what you had back then if you wanted to do anything remotely interesting.
it's yum -i apache actually 
I don't give a damn about who readers believe in. I'm not seeking for a job here.
Let me guess, by microcontroller I must assume some Java PIC, by your posts I *REALLY* doubt you would touch ASM even with a 10 feet pole.
"Java available for everything; crashing everywhere".
BTW: is that "elite coder" posture I use to find obnoxious; «I'm the coder, deem it unsafe, that unsafe, follow "my" standards, "teach"/"educate" users, all my systems are "good practices", all others' are "security by obscurity"...» GTFO!
I don't give a damn about who readers believe in. I'm not seeking for a job here.
Let me guess, by microcontroller I must assume some Java PIC, by your posts I *REALLY* doubt you would touch ASM even with a 10 feet pole.
"Java available for everything; crashing everywhere".
BTW: is that "elite coder" posture I use to find obnoxious; «I'm the coder, deem it unsafe, that unsafe, follow "my" standards, "teach"/"educate" users, all my systems are "good practices", all others' are "security by obscurity"...» GTFO!
Well... I'm the kind of guy where people goes AFTER being "well paying" consultants... and AFTER it goes down. That's why I'm amazed by your kind to keep being "well paid". 
If you believe you're able to fool anyone who's read our posts here - fine by me
I think you mistake low level microcontroller crypto implementation for "apt-get install apache" though. ("goes down"? really?)I really would love to know where you folks get those "well paid consultant" jobs!
You shouldn't be too surprised that us who do end up at the forum of the world's first possibly-successful crypto currency.
Well... I'm the kind of guy where people goes AFTER being "well paying" consultants... and AFTER it goes down. That's why I'm amazed by your kind to keep being "well paid".
I really would love to know where you folks get those "well paid consultant" jobs!
You shouldn't be too surprised that us who do end up at the forum of the world's first possibly-successful crypto currency.
I really would love to know where you folks get those "well paid consultant" jobs!
From his uncle...
I really would love to know where you folks get those "well paid consultant" jobs!
You really don't know what password attacks are all about, do you?
I spent a few years, as a well paid consultant, designing and implementing crypto security systems on embedded platforms.
You?
(Everything described in my posts would be considered "best practices")
There's no edging on encrypt/generate the salt
Adding layers of encryption/hashing does not always increase security while always increasing implementation complexity. Your schemes are simply unnecessary, it's better to increase the password entropy.
You may ADD OR REMOVE walls of his path
Yes, that's the "obscurity" part of your reasoning. It doesn't provide any added level of (real) security. When designing a security system all forms of added levels of complexity are risks where there might be edge cases you haven't thought about. You want as few implementation parts as possible, while still giving you a provable level of security.
You really don't know what password attacks are all about, do you? It's NOT a matter of being brutte-force proof, because there's NOT and never will be such a thing. It's a matter of TIME. The part that really matters is the attack TIMELINE:
0 m - plain text passwords broken
5 m - unsalted md5 <= 12 chars broken (Rainbow); unsalted ripemd160 <= 8 chars broken...
30m - salted (plain salt) md5 <= 10 chars broken
(...)
1 year - salted (plain) SHA256 <= 12 chars broken
(...)
This is what you can play with: TIME. If you call taken attackers time "obscurity", then it's your problem. There's no edging on encrypt/generate the salt.
"Educate users" is what fascists do! There's nothing to "educate" there. Good security is passive, active security is bullshit as the user will certainly need security against its "security". Humans are the central part to take into account, not the machines.
You may ADD OR REMOVE walls of his path
Yes, that's the "obscurity" part of your reasoning. It doesn't provide any added level of (real) security. When designing a security system all forms of added levels of complexity are risks where there might be edge cases you haven't thought about. You want as few implementation parts as possible, while still giving you a provable level of security.
In passwords the attacker is attempting to «GUESS» the password. You may ADD OR REMOVE walls of his path, ENTROPY.
Such system will ADD WALLS for him to break before «GUESS» what we wants to get.
Salt alone inputs a "NO PRE-COMPUTED HASHES" wall, but it's normally plain text on itself. Your objection is like saying that ADD A WALL is wrong because you think of it to be "obscure".
Such system will ADD WALLS for him to break before «GUESS» what we wants to get.
Salt alone inputs a "NO PRE-COMPUTED HASHES" wall, but it's normally plain text on itself. Your objection is like saying that ADD A WALL is wrong because you think of it to be "obscure".
Why everyone comes with "security by obscurity" without even KNOW what that stands for?!
In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".
In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".
Feel free to write coherent posts. Either the attacker has to guess (obscurity) or not. In any case, you're completely missing the point of salt if you feel that's a suitable place in a crypto system to add stronger complexity.
Why everyone comes with "security by obscurity" without even KNOW what that stands for?!
In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".
This is what I call "Fascistly Imposed Security".
We don't need no education
We dont need no thought control
No dark sarcasm in the classroom
Teachers leave them kids alone
Hey! Teachers! Leave them kids alone!
In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".
Quote
Educate the users instead.
This is what I call "Fascistly Imposed Security".
We don't need no education
We dont need no thought control
No dark sarcasm in the classroom
Teachers leave them kids alone
Hey! Teachers! Leave them kids alone!
would have to guess first which salting method was used
http://en.wikipedia.org/wiki/Security_through_obscurity
There's no reason to make the salt a part of the complexity of brute forcing passwords. Educate the users instead. "Password strength" indicators are one of several good ways of doing that.
I'm not sure what you're getting at, but I don't disagree with what you've said. Although we are veering further away from the topic at hand. Are you posing a question or other interrogative or just commenting?
I'm checking and demonstrating in terms of real code what you are discussing about; Salt generation.
In fact that $algorithm$salt$hash of crypt
the hash:salt of many systems
is a handicap on encryption.
But what resembles to be the best solution on this on-demand generated salt with Open Source software would be to create a salt class with different approaches and let the site owner to select which to use within config. This way an attacker would have to guess first which salting method was used before attempt to attack, and within the availabilities to generate the salt and input; xored strings, substring of hashes, multiple round sha hashing, bitwise etc... this would may means he would grow old before achieve something, even to the weakest of passwords.
Jump to: