Please, somebody figure out how to get us over the hump to the bright future day when we all have asymmetric keys embedded in hardware and we can leave passwords behind.
[deleted]
A bold but simple login system
21–30 of 101 posts
Re: A bold but simple login system
#22Please, somebody figure out how to get us over the hump to the bright future day when we all have asymmetric keys embedded in hardware and we can leave passwords behind.
Will/Should never happen. Human != device, and it's the human we want to identify to personnalize the service.
Re: A bold but simple login system
#23The problem with "solutions" like these is that they start with faulty premise that "passwords are broken". This particular idea sounds like death by a million cuts.
Re: A bold but simple login system
#24About the autocompletion: big privacy breach, would immediately quit and probably tell some authority about such stuff.
Re: A bold but simple login system
#25Please, somebody figure out how to get us over the hump to the bright future day when we all have asymmetric keys embedded in hardware and we can leave passwords behind.
Tada!
http://en.wikipedia.org/wiki/Security_token
Guess what? Even worse usability.
Re: A bold but simple login system
#26What's the overlap of users who (a) have trouble with login forms and (b) leave their email open all the time (whether browser or dedicated app)? This relies on a very high level of comfort with email and context switching.
This could potentially introduce an increase in spam if users are now instructed to click on links in emails blindly as long as they match a site that they're familiar with.
Leaving one app/tab for another seems like bad UX to me. This doesn't seem any better than the OAuth dance, even if it uses a much more seemingly familiar mechanism.
Re: A bold but simple login system
#27This is how Staticloud[1] works. You put in your email address and receive a log in link. You never have to register; registration and login are the same process. [1] http://staticloud.com/
Very interesting idea! Although I'm not sure that it would actually make it easier for users that don't do tabbed navigation (mom) to log from a second/public computer.
So, if elegant for power users, and 'not easier' for mom-users, should we implement it?
Re: A bold but simple login system
#28First things that come to my mind are privacy problems. This autocomplete would make it really easy to find out whether a person uses the service. (dating sites, porn sites, torrent sites, political sites,....). Additionally if the ologin happend only via the mail address, you could collect email addresses very easily from many websites.
Anyway, I like the idea of questioning the current way of user authentication!
Re: A bold but simple login system
#29First things that come to my mind are privacy problems. This autocomplete would make it really easy to find out whether a person uses the service. (dating sites, porn sites, torrent sites, political sites,....). Additionally if the ologin happend only via the mail address, you could collect email addresses very easily from many websites. Anyway, I like the idea of questioning the current way of user authentication!
There's always the argument that the register process leaks the same data. But having it appear in a dropdown makes it easier to incidentally see someone you might know.
Re: A bold but simple login system
#30Someone needs a history of internet mail. It was never designed to operate in real time or be fast, whereas people expect logins to be fairly quick. Also, using an email backchannel and one time keys moves the security from an encrypted connection (assuming SSL) to an unencrypted SMTP connection anyone can view... Back in the good old days of UUCP you might wait a day or two to get mail from across the globe...
Who really cares what it was designed to do? The fact is, almost the entire userbase is going to receive that email before they can switch tabs to their email inbox. So even though it wasn't designed to be immediate, it is in practice, and we have a whole list of technologies that we use despite intent (HTTP wasn't designed to be stateful, and yet we use it as such constantly).
Mail transmitting is only sometimes encrypted, which is disappointing, but I've yet to hear of an instance where a user account was compromised when the forgotten password link was hijacked by listening to the wire between two mail servers. If it really is a problem, this could also be mitigated easily by only allowing the link to work on the browser that initiated the request.
Frankly, though, I'd love it if this system were implemented if for no other reason than to encourage mail servers to enable TLS on their SMTP backend.