Posted by trlists on 04/12/05 14:40

On 11 Apr 2005 Richard Lynch wrote:

> > Well, just because I'm not sure it is worth the effort. What is the
> > point of storing a hash code as a proxy (in the colloquial sense of the
> > word) for an encrypted password if knowing the hash code gets you the
> > same access as knowing the password?
>
> Because the hash code will change VERY frequently.

Fair enough.

And I also take all the points about plaintext passwords. I don't
think anyone was talking about that (I certainly was not).

> You have to assume the user of the PW has been stupid and set the PW
> to the *same* PW as their bank account.

Fair enough. The approach I was talking about does not protect against
that and that is a flaw. The random token approach does a much better
job.

> > Just as an FYI, I'm partly playing devil's advocate here. I've never
> > written anything that stored the encrypted PW in a cookie (though I
> > have stored encrypted user IDs that way for a "remember me" feature).
> > I'm just reacting to the sense that there is One True Way to handle
> > this issue. In software development there are most often many good
> > options.

> *WHY* would you not store some kind of hash of the user ID?!

Because in that particular system no one considered the user ID to be
valuable. It is a little more complex to store and look up a hash, but
not dramatically so.

> > A digression to a related issue (where I did take the conservative
> > approach): A system I'm working on now was originally set up with
> > password hashes in the database -- the PW itself was never stored. But
> > the client wanted an "email me my password" feature so we had to
> > encrypt and store the PW. Of course if someone had access to the
> > database they'd get a lot of other stuff probably more useful than PWs
> > so I don't worry about this too much. But I would rather have used the
> > hash.
>
> Please tell me what URL that is. I want to BLOCK it so I never ever ever
> visit it. Thank you.
>
> Even my lowest-level stupidest password for the 10,000 sites I don't care
> about shouldn't be stored in clear-text !

Who said anything about *storing* the PW in clear text?? For the
record, it is stored encrypted, though I know this is weak protection
since access to the server gets you access to the decryption key. For
the web portion of this there is no visibility to the password at all.
For the email portion, of course there is as the password has to be
sent in clear text as it is useless otherwise. I personally would
prefer to use a "Reset my password" approach and display the new PW
over an HTTPS connection, but that does not meet my client's needs.
And "Email me my password" features are widespread -- used most often
on web-based discussion boards and the web-based interfaces for mailing
list software. Are you saying they are all wrong and no one should
develop or implement them, or just that you personally would never use
that feature?

On the general issue -- there are sites with login security practices
that are excellent, good, mediocre, poor, or nonexistent. What's
bugging me here is not the idea that we should know about and use good
practices, and from being willing to put forward my own questions I've
learned a lot about that in this discussion. What's bugging me is that
there is a tone suggesting that everyone should be using the highest-
level security practices for all data no matter how unimportant. I
have always learned that you match the security practices to the value
of the assets protected and the level of threat. A shed in my back
yard should be locked but it does not need an alarm system tied to the
local police. My house might. The local bank should do way better
than that. Etc. Web site security has the added problem that we do
allow people to use the same key for the bike shed and the bank, but
beyond that there are still tradeoffs and decisions to be made and not
everything requires the same degree of protection.

Also I think it is easy to forget about the difference in the level of
threat posed by a routine vs. rarely or randomly used feature. If an
encrypted password is stored in a cookie every user of the site is
vulnerable and the entire universe of user accounts is open to attack
if someone can figure out how to decrypt it. On the other hand an
"email me my password" feature is only open to attack when used and for
the people who use it. The number of systems or events which it
produces for attack is much smaller. That doesn't make it secure but
it is likely less of a threat than practices which create
vunerabilities automatically on every system which connects to the
site. This kind of discrimination seems to often be absent in the
discussions here, but when implementing seurity in a real system I
contend you have to do it.

--
Tom

[Back to original message]