Re: [Auth]<auth> tags, etc.

[Norbert Sendetzky]

On Thursday 26 July 2001 01:12, you wrote:
> But that's not the only use of even this limited standard,
> so the next question is: is it better to try to also define
> all the possible information usages, or simply use
> a separate tag for all requests this standard supports?
> For example, I may have an account with a web
> site for quite a while before I actually buy something
> and therefore encounter a request for credit card
> information. The request for a credit card number
> or for a shipping address is not authentication.
> Should that request reside under a different tag and,
> if so, what is it, other than a general request for
> personal information?

Perhaps we should name it "info retrival" instead of "auth".

> How exactly will any software behave differently
> based on the "type" of personal information request?
> I wonder if they would be more likely to care to
> differentiate based on the actual fields themselves,
> rather than any classification of the overall request.
> For example, I might like client software that lets
> me say "always ask me before giving out my email
> address", and having that constraint followed whether
> the email address is being given for authentication
> or for obtaining an e-newsletter, or permitting email
> notification of a physical shipment.

Me too! There may be the opportunity to do it on a per site basis or the 
requested information or both.

> Those are issues for the client software (which we,
> fortunately, don't have to write), but I would not
> forbid any HTTP method. Some systems use a GET,
> and not supporting it simply means they will continue to
> use it only without the convenience of supporting this standard.
> Someone standing behind your shoulder generally has
> multiple opportunities to steal passwords no matter what
> is masked on the screen (or at least keyboard reading
> was popular sport in the olden days when I went to college
> and mainframe account resources were difficult to come
> by).

My thoughts where about forcing the web site provider to provide https for 
authentication to encrypt the transmission.

> One could argue that forbidding GETs at least greatly
> reduces the opportunities for over-the-shoulder attacks.
> But keep in mind that we're building a single logon system.
> That means the attacker only has to read one password
> off the keyboard to get all your passwords. Perhaps it's
> better to push for users to learn that people can read what
> you're typing (even if it's not displayed on the screen),
> than to feel that eliminating GETs has appreciably
> increased security. I believe that telephone credit cards
> have had to go through this cycle of education already,
> at least in travel hubs at major cities, where a pair of
> binoculars used to provide thieves with a steady stream of
> stolen long distance credit.

We should use every way to increase security. Education is the one that will 
last longest and is the most difficult.


Norbert