Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Make it good

by hardburn (Abbot)
on Oct 18, 2004 at 16:47 UTC ( [id://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.

    radiantmatrix
    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?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://400217]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (7)
As of 2024-03-28 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found