Python Scripts to logon to websites

[Mike Meyer]

Peter Hansen <peter at engcorp.com> writes:
> Mike Meyer wrote:
>> Peter Hansen <peter at engcorp.com> writes:
>>>By the way, note that neither basic auth nor digest auth provide any
>>>real security, and in fact with basic auth the userid and password are
>>>sent *in cleartext*.  For any serious production site these techniques
>>>should probably not be used without additional security measures in
>>>place, such as HTTPS encryption.
>> To be clear, the HTTP authentication schemes don't provide any
>> security for the *content* that gets passed back and forth, and they
>> don't claim to. If someone can intercept that content, they can read
>> it. For some applications, this is really important. For others, it
>> doesn't matter at all.
> If someone can see the content, they can also see the userid and
> password.

Only if the userid and password are part of the content. If you're
doing the usual form-based authentication, then they are. If you're
doing an HTTP-based authentication, then they aren't - the
authentication information is in the headers, and can be protected
however the protocol designers want it to be.

> Most people on the web are simply too ignorant of security issues for
> those of us building systems that require passwords to ignore this
> issue.  To do so is to endanger the security and privacy of the very
> people you are hoping to have as users and customers, which is lazy
> and careless (and perhaps in some countries even criminal these days).

Most of the people building systems that require passwords on the web
are too ignorant of security issues for me to trust anything crucial
to them. I don't bank online, because the banking systems I've looked
at don't meet *my* minimal requirements for security.

>> Digest passes around md5 sums of varous bits and pieces. While md5 has
>> been compromised, I don't believe that's happened in a way that
>> compromises the security of digest auth. The password and username
>> that pass over the wire are about as secure as they're going to get
>> without noticably heavier mechanisms than digest auth requires. On the
>> downside, the server has to have the clear text password available.
> My information about digest was either obsolete or simply wrong, as I
> didn't realize it had all the nonce and anti-replay support it appears
> to have.  (I may have been remembering articles about how much of that
> wasn't supported widely at some time in the past, meaning replays were
> still quite possible in most cases.  No longer sure.)  Thanks for the
> correction.

Back when I was dealing with this on a regular basis, the major
browser and server vendors were all pushing encrypted session
mechanisms of various kinds. Given that, a secure authentication
mechanism is a waste of time, and would provide competition for their
product in some application domains. So those vendors typically didn't
implement digest authentication. This sucked if you were exchanging
content that didn't need security, but wanted to authenticate
identity.

> In my own opinion, however, requiring that passwords be stored in
> clear text on the server is still quite a bad thing to do.  I don't
> think even system administrators should ever have access to user
> passwords.  But many people don't seem to agree (or at least, are more
> than happy to be lazy rather than diligent in protecting their users'
> privacy).

Paul Rubin indicates that this isn't required - so my information is
out of date as well.

    <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.