|
|
Posted by trlists on 10/20/60 11:13
On 13 Apr 2005 Richard Lynch wrote:
> I have what I consider a MINIMUM standard level of security for any site
> that asks for a password.
>
> That would include:
> Not storing the password *ANYWHERE* in clear-text.
> Not in database.
> Not in $_SESSION
> Not in COOKIES
Agreed. I see less risk for temporary storage in $_SESSION in the case
where the server is well-protected logically and physically, but it's
so easy to encrypt (if session storage is needed at all) that there's
no reason not to.
> Not storing an encrypted username/password in $_SESSION/COOKIE if having
> those values provides access. Because at that point, the encryption is
> rather meaningless, as it's really a clear-text 32-character code that
> happens to be the encrypted value of something secret, but the clear-text
> 32-character code gives the Bad Guy access, whether they know the secret
> or not.
>
> If your content/application/data is important enough to warrant a
> username/password, then it should be important enough to secure with this
> minimal level of security, IN MY OPINION.
Here I think we disagree as by this logic no one should store anything
in a cookie that provides access (beyond a short temporary timeframe).
There are many kinds of sites where users want some privacy or control
over their own account but also want the convenience of staying logged
in, and where there is little or nothing any Bad Guy skilled enough to
go steal the cookie would bother with. For example, many discussion
board logins fit this description. I personally use a different
password for each one I'm on (it's not very many), and far prefer the
convenience of not having to go look it up every time over the
"security" of having it expire, particularly since the very worst
someone can do if they gain access is post as if they were me.
The analogy is that the Bad Guys who know how to break into bank vaults
just don't care about my (hypothetical) shed full of garden tools, and
if they do test their skills there, the garden tools aren't that
valuable anyway. And if in order to prevent this highly unlikely theft
I have to remember my key every time I go out to do some work, that's a
poor tradeoff to me.
What we're arguing about is whether the garden shed [web site] should
be designed so that I *have* to use a key (i.e. require a specific
level of security) or whether I as the user can choose. For anything
involving money or significant personal data, or other similar risks,
yes, to me the login security should be forced. But for less important
assets there are real benefits to security practices that give the user
more control.
Some of this is simply a question of whether there is a category of
stuff that is important enough to protect with a password but that
doesn't require more careful security, login expiration after a short
time and other protection mechanisms. I think that category exists,
sounds like you are saying you think it does not.
> If users forget passwords, they should get new random passwords, with the
> application/email directing them to change those passwords to memorable
> (to them) but hopefully un-guessable (to Bad Guys) values.
Agreed. My clients don't always agree but I think this is correct.
> I would contend that anything less is simply a false sense of security,
> provided to the un-informed, by using inherently insecure
> username/password methodolgy.
>
> The fact that 10 zillion sites are currently doing exactly that does not
> make it "right".
>
> You obviously disagree, and think everything is just hunky-dory in the 10
> zillion sites that are leaking passwords to any Bad Guy with half a clue.
Well I hope that was a bit tongue in cheek. I didn't say that nor do I
think that. There's a lot of bad security out there. That doesn't
make someone like me who disagrees with a particular set of security
principles into someone who thinks all bad security is fine.
--
Tom
Navigation:
[Reply to this message]
|