Mordred wrote:You don't seem to follow what I'm saying. Obscuring the names does reduce the impact of the breach, exactly by preventing the attacker from gaining the names of the variables and tables. It is a perfect mitigation tactic, because even though the attacker has just found an SQL injection hole in one of your scripts, but he cannot use it in any meaningful way, because he needs to know the name of your login table (for example).
I do follow, we simply disagree. I feel there are sufficient alternative methods available to the attacker to find the names. You instead offer ways to prevent that (an additional and separate security measure), which proves the point that there are alternative methods to do so (in fact, many beyond the methods listed).
Ask it the opposite way: If there is a method available to the attacker to get the table names, will a complicated naming scheme improve security, or simply increase difficulty in coding?
The Phoenix wrote:
Worse, it does cost something to the programmer. By memory, I can say that username=bob while coding. On the other hand, in your scheme, I'd likely need to check to see if username is actually field 'sirguhgh' or field 'guhffed'. If you chose fields with similar schemes (field names ooo1, ooo2, ooo3, etc), it would make it likely you would mistype at some point. Its relatively easy to see when you've used the wrong fieldname on username, not so with ooo2 v. ooo3.
Mordred wrote:Maybe this will make things clear. No additional effort is required from the programmer.
Thats an interesting approach I wasn't thinking of in terms of development. I'm not convinced on the debugging side of things that it would be simple, but I'll concede that on the development side its elegant.
Mordred wrote:I do not mean to offend you when I'm speaking of experience (everyone's experience is limited after all

), but "Security shouldn't fail" is not a way of thinking that comes from the voice of experience, it is a good wish written on water.
Four responses, all the last I will say on this portion of the discussion:
1. It is incredibly personal to say "That is not a way of thinking that comes from the voice of experience". If you feel I am not sufficiently experienced, that is an issue you should discuss in private messaging. I feel quite comfortable that at least a few of the moderators are aware of my background, and know that I not only have the experience to speak with the voice of experience, but that I also do not choose to contribute in areas outside of my expertise. Discuss the concept in public. Discuss your opinion about my experience in private.
2.
I never made the claim that security shouldn't fail. You rephrased my statements to fit that, and doing so was inaccurate. I said that security should withstand attack, not avoid it. That doesn't mean that security shouldn't fail. Its the difference between fighting a good fight (and losing), and running away. Obscurity runs away. Security stands and fights. Whether it wins is a question of resources and design on each side of the attacker/defender equation.
3. Obscurity is out of place with the rest of this article. It has nothing to do with hashing credentials. It is an unrelated suggestion that I've argued does not add substantial security. You can agree or disagree with that stance, but it still has no direct impact on the hashing of the credentials. If I use normal tables, and you use 'tricky' ones, would our resulting hashes be different? No. As such, whether you agree with it adding or subtracting net security, its not related to the key topic, and should be removed to avoid difficulty.
Mordred wrote:1. There is a terminology mixup, what you talk about is not a one-time pad (I'm too lazy to explain it, go check wikipedia).
In this one, the devil is in the details. If you don't wish to discuss the details, I can't explain why its an accurate use of the phrase. But it doesn't matter, because..
Mordred wrote:2. It is a chalenge token and you talk about using it in a challenge-response protocol for transmitting login data. This is what Maugrim's article deals with, and is what this article explicitly states that it doesn't deal with.
It explicitly states that it is about storage, but the title is misleading, as hashing does have concerns on both the transmission AND the storage side. The fact that multiple replies brought up transmission shows that I'm not the only one that would think so.
That said, it doesn't matter either, because..
Mordred wrote:3. As far as secure storage is concerned (which is what the article is about), storing an unsalted hash of the password is not secure enough.
This is the heart of your article, and what matters. The rest has all been a distraction. One of the problems is that the choice you advocate (not storing unsalted hashes) has its most direct impact on transmission - which you are forcefully asking not to discuss in this topic.
The two are related, and I can't discuss one without the other. Yet, you want to expand the discussion to include security v. obscurity, which is easily an entirely separate discussion which does not have direct bearing on your article. I'm challenged to understand that logic.
Mordred wrote:The Phoenix wrote:
I reiterate, I think the article was good, but its not the place for a security v. obscurity argument. It reduces the value of the rest of the information presented. It goes substantially against the real-world information security community, and as such, if it is to be covered, should be its own topic.
I would like to ask you to either present texts from the said "real-world information security community" which refute my argument or just refute it yourself. This is not a generic "security v. obscurity argument", it is a concrete application which does - I repeat - a
tremendously good job.
You are asking me to disprove the generic argument you have put forth (in the context of a specific area). I've made clear that the discussion is considerably larger than this article thread, and every discussion we've had confirms that. It is a sweeping discussion.
I've offered to discuss it in another thread, you declined.
I've offered specific refutations, you've argued, and I've offered to discuss it in another context, you declined.
Mordred wrote:I hope you don't find my spech offensive (excuse me if so), I am attacking your arguments, not yourself.
On the contrary, you've personally attacked my experience and knowledge. It is an issue best dealt with in private, and so I will.
The article was posted as a draft. You said "Comments, thoughts, fact and grammar nitpicks are very much welcomed. "
I provided them with both good intent, reasoned discussion, and no personal attacks of any kind. I think the article is strong, but since you asked "Do you think this needs expanding (or shrinking) in some direction? " The answer I gave was yes - one paragraph should be removed.
I have provided my opinion, and my reasoning. Discussion I'm happy to engage in, but this thread has devolved into arguing, and I have no interest in that.
Good luck with your article. Sincerely.