Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Make it good

by hardburn (Abbot)
on Oct 18, 2004 at 16:47 UTC ( #400217=note: print w/replies, xml ) Need Help??

in reply to Make it good

A nice list of rules, but what really makes software hard is when the rules end up being contridictory.

For example, for security reasons (rule #3), I never want to see a plaintext password in a database. Instead, I use SHA1 hashes with salt. The problem is that users forget their passwords, and when they come to ask us, we have no way of getting the orginal (thus breaking usability, rule #4). We have to set the password to something else and give them that. IMnHO, this is perfectly reasonable, and the random password we give them is probably more secure than whatever they were using before (their dog's name, favorite food, etc.). As far as I'm concerned, users who don't like this are themselves a security hole. Management doesn't agree, so now it's plaintext passwords everywhere.

As a side (and off-topic) note, I'm convicinced that password authentication is a failure. I read a book by a conviced cracker written about 15 years ago (sorry, I don't remember the name, but I do remember that it was (ironicially enough) published by the Microsoft Press). He said the biggest security hole is your own users, and highly emphisized the need to train your people, especially with regards to passwords. If we haven't succeeded in doing this by now, I don't think we ever will.

Unfortunately, password authentication is often the only practical option at this point.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re^2: Make it good
by radiantmatrix (Parson) on Oct 18, 2004 at 17:11 UTC

    You make an interesting point, and one I will probably have to incorporate into the node. These rules could easily contradict each other -- except that they are not absolute rules.

    In your cited example, you have to decide whether security or usability is more important in that particular case. Rules like these don't remove the power and responsibility of making choices, they just provide a framework to guide those choices.

    Also, this is arguably a bad example: it is secure, so it hits rule #3. It's also usable, so long as the password reset capability is easy for the support staff to use. The idea behind these rules is that they are flexible enough to fit your specific circumstances.

    require General::Disclaimer;
    "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://400217]
[shmem]: good morning monkses and monksisses
[choroba]: Good morning!
[shmem]: GDPR meets butcher's shop
[marto]: if only Spectre had remained a fictional organisation :P https://www. php?page=news_item &px=Spectre-V3-V4- Vulnerabilities
[marto]: 'GDPR meats butcher's shop'?

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2018-05-22 07:21 GMT
Find Nodes?
    Voting Booth?