[Owasp-topten] Insecure Cryptographic Storage

Neil Smithline owasp-topten at smithline.net
Sat Apr 4 20:13:10 EDT 2009


Actually, one can never be certain that there is not one or more cleartext
copies of their password on the server. The problem arises because there are
a constant stream of cleartext passwords being sent to the app server.

When using SSL, passwords are encrypted on the client, sent to the server,
decrypted by the network layer (this is key), and then hashed or two-way
encrypted by the application or, in some cases, the user store (eg: LDAP &
RDBMS systems have this capability).

This means that from the time the password is decrypted by the network layer
until the time it is encrypted by the application or user store, it is in
cleartext. While the cleartext version is not stored in the database, it can
be written to disk in a core dump, by OS paging, etc...

I think the worst case is in Java and other languages that have immutable
strings. In these languages, HTTP/S requests are passed to the application
in cleartext, immutable strings. The best the application can do is to
carefully and quickly encrypt/hash the password and remove any pointers to
the cleartext string so that it can be garbage collected. This is far from
easy as the request has a pointer to the cleartext password but the request
also has lots and lots of other data in it. While I have never heard of one,
an app server that has the ability to securely discard the password  would
be a big help. Unfortunately, I know of none that do.

So, even if you go through all of the trouble described above including
copying everything you need out of the request and releasing all pointers to
it, you still cannot know the score. For starters, the app server makes no
promise that it will discard requests. In fact, the better app sever
typically cache old requests and reuse them for performance reasons. And,
the worst part is, even if you do all the hard work and your app server
plays nicely and lets the password go, and that the string is immediately
garbage collected, all that happens is that data buffer is returned to the
heap. Until that portion of memory is reallocated, the password is just
sitting in the heap.

Transmitted passwords are a simple but insecure means of establishing trust.
Digest authentication seems somewhat better as the cleartext password is
never transmitted. But, the cost of digest authentication is that passwords
must be stored in a reversible data format (eg: encrypted) in the user
store. Not necessarily a problem, but a risk. SSL with mutual auth is
better. RSA SecureIDs, SMS messages, one-time passwords, etc... are all,
IMO, significantly better.

Neil


<http://www.smithline.net>Founder & Senior Security Consultant
OneStopAppSecurity.com
https://www.OneStopAppSecurity.com
Voice: 781-754-7628
Fax: 206-666-5090


--- @ WiseStamp Signature. <http://www.wisestamp.com> Get it
now<http://www.wisestamp.com>


On Fri, Apr 3, 2009 at 22:13, Ray Foo <gunblad3 at gmail.com> wrote:

> For one-way functions, it's not practical/possible to retrieve the original
> text given the result, which is good for passwords since we only want to
> know whether the user has entered his own password correctly (i.e. the
> hashes should be the same) without having to know the actual password
> itself.
> As implied in the name two-way encryptions, it is possible to get back the
> original message given the key, which is an unnecessary risk in terms of
> password management given our needs (see above).
>
> Ray.
>
>
> On Sat, Apr 4, 2009 at 9:44 AM, Zaki Akhmad <zakiakhmad at gmail.com> wrote:
>
>> On Sat, Apr 4, 2009 at 1:03 AM, Anurag Agarwal <anurag.agarwal at yahoo.com>
>> wrote:
>>
>> > To break it down a little bit, if the application is allowing a user to
>> > retrieve their old password, that means it is stored either in clear
>> text or
>> > two way encryption (both of them are bad practice, one worse than the
>> > other), if they are making the user select a new password, though they
>> may
>> > still be storing it in cleartext or two way encryption but the chances
>> are
>> > it is probably hashed and stored.
>>
>> I am a little bit confused with "two way encryption" words. Are there
>> "one way encryption"? What's the difference between hash function aka
>> one way function?
>>
>> > Web: www.attacklabs.com , www.myappsecurity.com
>>
>> Both of them inactive?
>>
>> --
>> Zaki Akhmad
>> _______________________________________________
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-topten
>>
>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-topten/attachments/20090404/51d70ed7/attachment.html 


More information about the Owasp-topten mailing list