Info about the recent attack

[BCEmporium]

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.

[defxor]

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.

[BCEmporium]

I really would love to know where you folks get those "well paid consultant" jobs!

[Raoul Duke]

I really would love to know where you folks get those "well paid consultant" jobs!

From his uncle...

[defxor]

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.

[BCEmporium]

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".

[defxor]

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?)

[BCEmporium]

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!

[defxor]

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 12^a. 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.

[BCEmporium]

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.

[phillipsjk]

For the record, this is the security through obscurity:

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).

[BCEmporium]

For the record, this is the security through obscurity:

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.

[Xenland]

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]

[deepceleron]

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.

[defxor]

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.

I lol'd.

Assuming just lower case + upper case + numbers, no special chars, that's 62^50. Converting to a more familiar base 2 representation it's equivalent to 2^298. Tell me, in which universe where you planning on storing that rainbow table, and for how many heat-death-of-the-universe-eons were you planning on creating it?

When you fail at math, you fail at crypto. Hard.

(edit: Number of atoms in the visible universe: 2^266)

[BCEmporium]

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.

I lol'd.

Assuming just lower case + upper case + numbers, no special chars, that's 62^50. Converting to a more familiar base 2 representation it's equivalent to 2^298. Tell me, in which universe where you planning on storing that rainbow table, and for how many heat-death-of-the-universe-eons were you planning on creating it?

When you fail at math, you fail at crypto. Hard.

(edit: Number of atoms in the visible universe: 2^266)

It's an expression, not a math number. I merely mean that if a single hashing algorithm was used in the planet, the RT for it would be by now enough to consider such algorithm more than broke. By having diversity, the hashing power has to split over the options, slowing down the process...

[defxor]

I merely mean that if a single hashing algorithm was used in the planet, the RT for it would be by now enough to consider such algorithm more than broke.

We understand what you mean. We're just proving you wrong.

Sadly you don't know enough math to understand it.

[BCEmporium]

Wrong in what?! 

That a 62^50 db is impossible to store? It is... at least so far, and even if possible to store would be impossible to query.
But your statement proved that you, sir, are a "square", unable to understand expressions and taking everything to literal arguments. Probably your brain has fused with your CPU already...

[defxor]

Wrong in what?! 

Everything you've posted with regards to the utility of security-by-obscurity.

That a 62^50 db is impossible to store? It is... at least so far

It's many orders of magnitude larger than the number of atoms in the universe. You fail at simple math.

[BCEmporium]

One guy came up with an idea: crypt the salt. I followed that idea, because unlike "square boxes", I like to follow ideas and see where they can get us.
Dodging arguments, some "square boxes" instead of looking for flaws came up with "security trough obscurity", an "argument" as valid as call someone "fascist" or other long-shot meaningless name.

It's many orders of magnitude larger than the number of atoms in the universe. You fail at simple math.

So I must assume we know the entire universe. Rather call it a day, we call all science academies to shut off, because defxor here just came with a number of atoms in the universe. Nothing more to see, humanity has done its job.