In general, there are four things to be aware of:

1. Credentials encoded in the URL are very easy to accidentally leak
   in any outgoing Referer headers, in screenshots, etc. This can be
   mitigated, but it's also easy to mess things up.

2. Credentials encoded in the URL will by default end up in the logs
   of the HTTP server - although again, this can be fixed. They may also
   get recorded by various proxies, AV tools, browser toolbars, etc -
   which is a bit harder to contain.

3. The user will be dependent on having access to bookmarks or some
   other way to retrieve that URL to be able to log in from a particular
   computer, since it's impossible to remember; and if his bookmarks are
   deleted or corrupted, you will need to deal with account recovery. If
   you are willing to put up with this, you may also want to consider
   client SSL certificates or so as an alternative form of
   authentication.

4. Since all the information needed to access the account is stored on
   the computer, any system compromise can be used to recover the access
   token immediately, rather than waiting for the user to interact with
   the targeted site. This may or may not matter.

/mz

Glen,

Check out this paper that advocates the use of such identifiers instead of
session cookies and other ambient credentials:

Web-key: Mashing with permission
http://w2spconf.com/2008/papers/s4p2.pdf

It addresses the 4 things that Michael listed and
it's generally a very pleasant read

Cheers
Nick

On Mon, Jan 28, 2013 at 6:55 PM, Michal Zalewski lcamtuf@coredump.cxwrote:

Glenn, it's considered best practice not to send auth tokens in URL due to risks of upstream logging , also proxies and firewalls may log it and then making it permanent would only increase the risk.

Thanks
Subin

Sent from my iPhone

On Jan 28, 2013, at 4:13 AM, Glenn Pierce glennpierce@gmail.com wrote:

Well said but kick it up a notch. I actually recommend keeping all
sensitive data out of URLs for just this reason. Passwords, PII,
Authentication tokens - anything you do not want leaking should stay out
of URL's (HTTP/S GETS).

The more positive rule is to only submit sensitive data over HTTPS POST.

There are of course additional sub rules in the age of AJAX and JSON,
but this is a good start.

Cool?

Jim Manico
@Manicode

Thanks for the good ideas everyone. I have a few things to think about.

When accessing through https what will upstream proxies log ? Just
the encrypted url right ?

On 28 January 2013 09:13, Glenn Pierce glennpierce@gmail.com wrote:

Depends on the proxy and its functions. Many proxies now monitor SSL
traffic by acting as a go between.
On Jan 28, 2013 4:16 PM, "Glenn Pierce" glennpierce@gmail.com wrote:

yep, after the domain name its all encrypted via http(s). but it would still be in the clear in the web server logs.

-phil

On Jan 28, 2013, at 3:07 PM, Glenn Pierce glennpierce@gmail.com wrote:

Upstream proxies only have visibility over the network information
(hostname, IP and port, etc.) for HTTPS connections.  That is, if they're
not acting as MITM proxies on purpose or not.

Regards,
Ray

On Tue, Jan 29, 2013 at 5:07 AM, Glenn Pierce glennpierce@gmail.com wrote:

People often do confuse whether URI is encrypted when HTTPS is used. It is indeed and as phil mentioned, only domain name and a bit other network information is logged on transparent proxies. T
Though password less login is great idea, it has some practical disadvantages like remembering very long URL with token, expiry of those tokens. It might work in some small set-up of enterprise level web app but difficult to scale in multi-user applications.

-Rohit 

From: BSDwiz bsdwiz@gmail.com
To: Glenn Pierce glennpierce@gmail.com
Cc: "websecurity@lists.webappsec.org" websecurity@lists.webappsec.org
Sent: Monday, January 28, 2013 4:23 PM
Subject: Re: [WEB SECURITY] Password-less login ?

yep, after the domain name its all encrypted via http(s). but it would still be in the clear in the web server logs.

-phil
On Jan 28, 2013, at 3:07 PM, Glenn Pierce glennpierce@gmail.com wrote:

Thanks for the good ideas everyone. I have a few things to think about.

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org