We're working on replacing our dependency on MyOpenID for new account creation. Basically, replacing the click here to sign up
link on /users/login
.
The experience has never been really stellar. You click a link, end up on a new page on a new site, with Stack Overflow (or Stack Exchange) dwarfed by MyOpenID's logo... it's a tad confusing for the not so tech savvy user.
Plus MyOpenID keeps having [1] issues [2] . Right now, for instance, their Captcha is forcing you to waste an extra click during signup.
To this end we're introducing
openid.stackexchange.com
[3], our own (beta) OpenID provider.
Yet another OpenID provider isn't going to set the world on fire, clearly, but we will be integrating this more tightly into our sign up and registration flows.
The link on meta
[4], for example. The click here to sign up
link will ajax in the signup form.
We've added a Stack Exchange button a la Google or Facebook; so sign in won't be any more complicated when using this provider. You can also type openid.stackexchange.com
or stackexchange.com
into the login form to accomplish the same thing.
We've done a fair amount of internal testing, but no code survives contact with the enemyuser base. Give it a spin, and let us know ifwhen and how it's broken.
We're not aiming for 100% of the sites that support OpenID to accept us for logins, there are a lot of poorly written libraries out there after all, but most should (wouldn't be a very good license [5] if they didn't). If you encounter a site that you think should accept our credentials, and doesn't, do please report it.
We're also looking to streamline logins with this new provider, ideally making it so that a normal user would be unaware anything more sophisticated than standard U/P login is going on.
Note that the click here to recover your account
link is re-written to point to the Stack ID account recovery page when the inline login form is shown.
If a user is logged into OpenID.StackExchange [6] already, they'll get prompted to authorize the site.
... but only the first time. If logged into OpenID.StackExchange [7] and the site in question has been logged into in the past, the button will be a "one click login." No prompting at all.
I'm sure a lot of people reading are wondering "why should I trust you to store* passwords correctly?". I can sympathize, after all we write garbage code [8] with bugs [9] (and lots of people get it rather wrong despite not being us).
Go review the code
[10] to convince yourself; we're open sourcing** this before we (properly) announce and deploy it.
Raise issues
[11] on anything you find, get in touch via the contact us
link, or post it here. We're not accepting new functionality just yet, just reports (or fixes) for existing problems.
*And probably chuckling about the idea of actually storing passwords.
**With the exception of an alternate implementation of
Email.cs
[12], which relies on a third-party, closed source, library.
I registered succesfully and I tried a couple of interesting vanity ids
http://www.facebook.com/default.aspx
- Sklivvz
.
in an initial or final position. Maybe you should just forbid .
altogether. And insist on at least one letter. (Not sure if I should be -
, or 0
. .
or ..
redirects me to /
, ...
404's.) - Gilles
user
(“Vanity OpenId can contain letter, numbers, periods, dashes, and be up to 40 characters.”), but I can be account
. - Gilles
/user
. - Kevin Montrose
.
character. If I can find a reasonable workaround for .cshtml I'll even remove that constraint. Don't really see the point in restricting vanity ids, they're meant to work around the already kind of crummy situation where a relying party isn't satisfied with just openid.stackexchange.com
. - Kevin Montrose
Tried to sign up and accidentally used a malformed email myemail+stackexchange.com
, forgetting to add the @gmail
part. I saw no indication of any problem, just never got an email.
Not sure if email validation is part of what you're currently looking to test, but it took a while to figure out. Guess I've got a bad case of the Mondays. I didn't notice it until I tried to sign up again and the field was auto filled with the incorrect version. :)
Upon registration, my randomly generated 8-character password (letters of either case and digits) was rejected for not having 8 different character. Hmm, you're rejecting 38% of a class of passwords with 47 bits of entropy. I should crank it up to 16, I suppose.
Openid.SE doesn't automatically trust stackoverflow.com
as a relying party. I suppose it will once it's in production.
/users/login
on SO, SO will be trusted by default (at least, it should be and has been in our testing). If you go straight to openid.SE (which will be very unusual) this is not the case. We don't want somebody to create an account for a non-SE site and get opted into giving us their info, basically. I'm also philosophically opposed to special if Stack Exchange then ...
code being added to the project (with the email exception noted above). - Kevin Montrose
/users/login
rather than go to openid.SE's registration page. - Kevin Montrose
password
as password. Requiring uppercase, special characters, numbers and at least 8 characters is really much for something that isn't a bank account (for which I remember once upon a time only exactly five(!) characters could be used...) - Tobias Kienzler
If you try to recover a password with a non-existing email you get the message:
No account with that email was found
Which actually could be used by an attacker to determine whether a login exists or not, whereas upon logging in with an incorrect username and password combination, the error reads:
Unknown email or incorrect password
So, they are inconsistent in intent, and they should be fixed by adopting one of the two following options:
Option A: you want to keep the site as secure as possible. No information should be leaked by the recover password page, login should stay as-is
Option B: you want to be friendlier to the user. Keep the recover password as is, but change the login screen to specify which field (username or password) is the source of the error.
"... a CAPTCHA for password recovery as it prevents brute-forcing it"
. I was simply pointing out that it does not do that. - AviD
Very long emails produce unexpected results on registration
I've tried with a 15kb email name and it apparently kills the request at some point. The error returned is:
Captcha failed - The verification words are incorrect.
Whereas, my captcha was actually OK (I've tried three times).
15kb email names do fit in the textbox so either reduce the textbox max-length or make sure the system supports those email values.
Note: Login and password recovery work quite fast with the same long email.
Test case: averylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusernameaverylongusername@mailinator.com
Tried to add on sourceforge.
I got : https://openid.stackexchange.com/account/login/submit a 404 when submitting the first time and now :
Cannot Complete Login
Detected an attempt to send an assertion when the identifier (http://openid.stackexchange.com/) is not owned by the logged in user.
If you believe you encountered this message in error, please report it.
I think it's because I didn't put my username in the address when I tried. Google does not requires to put a usename when used. Can we do the same? You put openid.stackexchange.com and it returns openid.stackexchange.com/mvyonline (being my vanity one BTW)
Argh... and if you forgot to put httpS
your denied too... even if you are login on the HTTPS version of the site.
At the end sourceforge refused it ... Could not verify your OpenID. Please try again.
openid.stackexchange.com
or stackexchange.com
). - Kevin Montrose
Using a vary standard email (my own gmail) it worked (almost) flawlessly:
I started with a very basic password which got the read sign on the right. It let me put the same password on the second box and submit, though. I then got the response that the password was not complex enough and then added a new one and resubmission was fine. I don't know if that's the intended behaviour or it should not even submit if the password is not complex enough. In any case, it's quite minor. Good job :)
Now testing foreign characters, it doesn't work that well:
email: ñóúíéá@úñíóéé.com.yyzz
Name: húúíóñßüáúbb áßúbíóó
Password: ASDFqwerty01
When I hit send confirmation email button, it stays for a while "waiting for openid.stackexchange.com...", until it fails "Captcha failed - The verification words are incorrect" (several iterations of the same, I may be bad typing, but not that bad :)
Browser Chromium 11.0.696.68 (Ubuntu 11.04)
Password reset works just fine (and I loved the joke, I was laughing alone at work)
Validation on the profile page is inconsistent.
Putting a very long name is OK on the client side and a validation error is reported on submit:
Name is too long.
Putting a very long vanity id is caught on the client side and a validation error is reported instantly in a different place on the page.
Cannot be more than 40 characters long.
I like that plussed eMail addresses are supported (the plus symbol is a valid part of the local-part, which comes before the @ symbol, according to the relevant RFCs).
This ID system seems to be working well. I did try to get set up with the other OpenID provider that you folks recommend, but there were some problems with the registration and then their administrators didn't answer the eMails I sent to them.
Thanks for providing this alternative which resolved my problem.
The signup dialog has an iframe border in IE8: