Earlier quoted context omitted.
Great site! Sadly I got an error trying to log in with Google.
Ouch - I don't seem to be able to reproduce it but we'll take a look. Do you mind emailing me on [redacted] to discuss?
Will do now :)
A bold but simple login system
91–100 of 101 posts
Re: A bold but simple login system
#92Earlier quoted context omitted.
How is your solution better than a third-party cloud solution?
One obvious benefit is that you aren't trusting anyone else with your passwords.
Reputable password sites can't unencrypt your passwords. You trust the site to not have XSS flaws and to not be malicious. Outside of banking and email passwords, that doesn't seem like a huge risk.
Re: A bold but simple login system
#93Earlier quoted context omitted.
Yes, I remember that. Ugly solution that didn't expose a UI for sites that didn't support it and still had plain username/password forms. So it's completely impossible to bootstrap this by making some of the features useful to browser users before it was widespread. Needed a js library because it worked at the wrong level of abstraction and put browserid.org in the middle of the transaction for no sensible reason (we…
The persona.org middleman is only used when your email provider doesn't support BrowserID. It is temporary. It is useful to browser users today. You don't have to remember a new password for each site or become less secure by giving the same password out to multiple sites. I'm going to use it on the next site I build.
I should have been more clear. I don't like browserID because there is no route for this to become widespread except for "a significant portion of sites implement this".
You know that saying about any spam solution that begins with "well first we change email" is a stupid solution? Same issue here.
First you need a good password manager front and center in the browser. Then you start augmenting the experience by allowing better integration with the password manager through some standard. If the user already uses the functionality for every site and the experience is better on sites that implement the standard then you might actually see real amounts of integration.
Re: A bold but simple login system
#94Earlier quoted context omitted.
The persona.org middleman is only used when your email provider doesn't support BrowserID. It is temporary. It is useful to browser users today. You don't have to remember a new password for each site or become less secure by giving the same password out to multiple sites. I'm going to use it on the next site I build.
I should have been more clear. I don't like browserID because there is no route for this to become widespread except for "a significant portion of sites implement this". You know that saying about any spam solution that begins with "well first we change email" is a stupid solution? Same issue here. First you need a good password manager front and center in the browser. Then you start augmenting the experience by allo…
As a web developer, I think that using BrowserID in its current state without browser support is better than implementing my own authentication. As a web user, I'd prefer to use BrowserID to sign up for sites than use individual authentication systems. A system that is better for developers and better for users has a clear path to adoption.
Re: A bold but simple login system
#95Earlier quoted context omitted.
I should have been more clear. I don't like browserID because there is no route for this to become widespread except for "a significant portion of sites implement this". You know that saying about any spam solution that begins with "well first we change email" is a stupid solution? Same issue here. First you need a good password manager front and center in the browser. Then you start augmenting the experience by allo…
As a web developer, I think that using BrowserID in its current state without browser support is better than implementing my own authentication. As a web user, I'd prefer to use BrowserID to sign up for sites than use individual authentication systems. A system that is better for developers and better for users has a clear path to adoption.
I agree. BrowserID is a good authentication solution.
It's not a solution to the problem we're talking about though, I'm complaining about a lack of solutions for easy credential management.
Once everyone implements it then sure, you only need to remember your email password. Unless you have multiple personas, then you'll have a bunch of passwords. And realistically there will be a lot of sites that have different systems or antiquated username/password forms.
So aren't we back were we started? I need a password manager and I'd like my browser to be aware of my password manager and help mediate. BrowserID would be a great place for it to send the appropriate password for sure.
Re: A bold but simple login system
#96So what happens when someone's email account is compromised? Currently there's a fair chance that the victim can reset passwords and change contact info for their online services before the hacker bothers to do so. But this would be impossible if email were used as the sole form of authentication.
The same thing that happens now. Malicious user can recover/reset their password.
I'd assume that if you used the email to login and since the article talks about also using cookies with expiry dates in the future the codes in emails would be single use.
Re: A bold but simple login system
#97I've been working on a demo of something similar. It's a work in progress, but I've got it running at http://nopassword.alexsmolen.com. Code at https://github.com/alsmola/nopassword.
Not only can you register and login with only and email, you can review and revoke your active sessions.
People who are complaining about the speed of email - the session could last indefinitely until you log out, which would reduce the number of times you had to perform the ceremony. Plus, think about the benefits of this when you need to authorize a TV, phone, etc. You can simply visit a link in your email instead of copying and pasting or typing in those form factors.
I'd also like to integrate SMS to support optional dual-factor authentication, which should get help fix the single point of trust problem.
Re: A bold but simple login system
#98Thinking of it for enterprise users it could really work. Enterprise users seem to be on Outlook all the time checking their e-mails so this would work if you can't tie your passwords into AD/Exchange. Maybe have an option to have a token that can be entered or a link clicked. I get all my e-mails on my phone so if I received a code that I can enter in my phone that can work. I could also click a link in Outlook and…
Now if someone has my phone which is receiving my e-mails At work we have a policy that smart phones are locked by a PIN. No PIN, no email. This is not ideal: no mechanism to enforce 'good' PINs, force a user to change them on a regular basis.
Good point.
Re: A bold but simple login system
#99Someone 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 enc…
> So even though it wasn't designed to be immediate, it is in practice,
But that's by accident, not really by design, and because email isn't supposed to be immediate, and is often outside the user's control, there are very many things that can delay it.
Re: A bold but simple login system
#100Apple should augment a single sign-in mechanism with a transparent 2nd factor embodied in the iPhone. This would result in your being automatically logged into any participating site while using Safari on the same LAN as your iPhone. The mechanism would fall back to the traditional password if you don't have the phone. Bluetooth could also be used to communicate to the hardware. The hardware would only run signed App…
Google already does this with Chrome and Google websites. I don't have to enter my second factor with credential or even my password when using Gmail from my phone, tablet, laptop or desktop.
Yes, but I'm not so sure that's really two-factor authentication.