share
Meta Stack OverflowHelp us test and vet StackID (Stack Exchange OpenID)
[+62] [10] Kevin Montrose
[2011-05-12 20:56:31]
[ discussion openid ]
[ http://meta.stackoverflow.com/questions/91039] [DELETED]

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.

We've soft-launched this 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.

what you should see

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.

login inline on the page

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.

authorization prompt

... 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.

(27) Unfortunately Stack Exchange is the only thing I use OpenID for so I can go and test it on any other site, unless I go hunting... - Scrooge
So far working fine for me. It's certainly interesting. - Grace Note
What's a valid format for the vanity openid? - Scrooge
@ChrisF - it is something that should be explained (on it). <= 40 chars, numbers, letters, and . only; for the record. - Kevin Montrose
Thanks - I used "-" which is not on your allowed list :( - Scrooge
(5) Belongs on sqa.stackexchange.com? :-) - Sklivvz
@ChrisF - I've loosed that restriction, - is now permitted. Added some client side checks, and a better error message hopefully). - Kevin Montrose
(2) No, @Sklivvz, it belongs on security.stackexchange.com ;) - AviD
@Kevin, admittedly its quite late, and I've only barely glanced at the code - but so far, it looks to be some of the more secure code I've seen. Will try to spend a few more cycles later in the week to do a proper review, but I'm quite swamped now. - AviD
(1) Um - I'm changing my accounts to use SE's OpenID and it all worked fine (apart from an initial glitch I haven't been able to repeat) but now I'm just getting the "..." animation on Stack Apps stackapps.com/users/… - Scrooge
@ChrisF - it was a configuration error on StackApps, I've fixed it. Give the settings a few minutes to propagate, and try again. Thanks for the report. - Kevin Montrose
[+15] [2011-05-12 21:50:22] Sklivvz

I registered succesfully and I tried a couple of interesting vanity ids

  • Default.aspx
    Result: accepted but doesn't work (404)
  • index.php
    Result: it works (and I'm currently using it [1])
[1] https://openid.stackexchange.com/index.php

As an interesting side note http://www.facebook.com/default.aspx - Sklivvz
Thanks for the report, ".aspx" shouldn't cause errors anymore. I've had to forbid ".cshtml" though, for similar reasons... perhaps a solution will present itself in the future. - Kevin Montrose
(1) @Kevin: You'll surely want to forbid . 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
More vanity ID fun: I can't be user (“Vanity OpenId can contain letter, numbers, periods, dashes, and be up to 40 characters.”), but I can be account. - Gilles
@Gilles - a better error message is returned in that case now. Basically, you can't "cover" an already registered route, such as /user. - Kevin Montrose
(1) I would prefer that it keep the decimal character. For instance on facebook I am facebook.com/cole.brand - jcolebrand
@drachenstern- I have no intention of forbidding the . 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
1
[+12] [2011-05-16 13:15:06] yhw42

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. :)


(1) Good catch, there were two problems there. One, we didn't validate e-mails (oops, I blame me); Two, if an error occurred sending an e-mail we didn't tell the user. Both have been fixed. Thanks again for the report. - Kevin Montrose
2
[+10] [2011-05-12 23:37:27] Gilles

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.


While we could just do an entropy check, that's pretty hard to explain to people when compared to a unique character check. If you signup via /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
@Kevin wait, why can't I goto openid.SE directly? - jcolebrand
@drachenstern - you can and we support it, I'm just saying that the typical new user will use the form on /users/login rather than go to openid.SE's registration page. - Kevin Montrose
(1) @KevinMontrose ahhhh - jcolebrand
(5) @Kevin I don't see the need for having these crazy password restrictions - if users don't want to use a complicated, hard-to-remember password, why should they be forced to? - Kyle Cronin
(1) @Kevin yeah, you shouldn't forbid using 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
(3) @Kyle et al: I actually think it's a good idea to require a complex password, even if 8 different characters is a little stringent. If the typical usage is for SE auth, writing it down would be a lot safer than using a weak password. - Gilles
@Gilles With the exception of moderator accounts, what's the danger in using a weak password? Stack Exchange doesn't store any private data, and regular user accounts can't do any damage. - Kyle Cronin
(4) @Kyle - this is an OpenID provider, we can't assume the login isn't used for something more sensitive than a Stack Exchange account (although that will often be the case). Password requirements need to be pretty strict accordingly. - Kevin Montrose
(3) @Kevin Shouldn't that be up to the user though? Certainly you wouldn't prevent a user from using a strong password even if you allowed less-strong ones. The only case where your password requirements might make sense is if your systems were compromised, everyone's password hashes were exposed, they could be easily cracked, and your users used the passwords elsewhere. (cont) - Kyle Cronin
No other scenario makes sense - SE can throttle brute force attacks, if the login system is compromised password strength is useless, and like I said above, even if the user's password is compromised, the damage it can do on SE is quite limited. So in all cases, SE is not affected by the strength of the passwords of their users. On the flip side, the strong password requirements will likely cause many people to avoid using the service, and stick with their Google or Facebook accounts, both of which have far fewer restrictions on what the password can be. - Kyle Cronin
(2) @Kyle - By that argument 1 character passwords should also be fine. Continuing (even preferring!) to use Google, Facebook, et al for login is also 100% OK. I also fundamentally disagree that user's should have a choice in "how secure" they are, people are really bad at security as a rule. - Kevin Montrose
(2) @Kevin This is an issue of degree - how secure can you force people to be before they either avoid your service or sabotage your attempts to "secure" them. For example, someone may have a password they would like to use, but it might not have 8 unique characters, so instead they use "abcdefgh" or "12345678". Or they make up a password but know that they won't remember it, so they write it down somewhere that anyone that's near them could see it. Pragmatically, most people are used to a 6-character password minimum, so it would be fairly safe to use that as a requirement. - Kyle Cronin
@Kyle - 8 characters is already a compromise for convenience (offset by the unique constraint, in theory), suggested password lengths vary but 10+ is a pretty safe bet (here's a reference for 14). People can hardly sabotage our security anyway, they've got loads of other log in options; I see no point in weakening our system so as to entice people to more readily give us sensitive information. - Kevin Montrose
(2) @Kevin I was referring to your attempts to secure the user by forcing them to provide a complicated password, not the security of SE itself. It is, of course, your feature so you must do what you think is best. I'm just trying to say that your password requirements are needlessly driving away some potential users, myself included. - Kyle Cronin
(4) @Kevin: I think this would make a good question on Security.SE: given StackID's purpose, what are reasonable password constraints? - Gilles
@Kevin, can I suggest popping this issue up as its own question on security.stackexchange.com ? You're likely to get a better, more balanced response their from the experts on this. - AviD
@AviD @Gilles - Isn't this comment thread alone proof enough that such a question should be closed as subjective/argumentative? - Iszi
@Iszi hehe, but on ITsec it could get reasoned arguments, based on security implications and sound risk/business tradeoffs. What we do best :) - AviD
(1) @AviD - Sure, lets move this over there. - Kevin Montrose
Remind me of xkcd.com/936 . All the password check rules that are based on computer/mathematical rules don't fit the human mind. Worst, since each site has its own rules, you end up with so many stupid password, you'll finish using 'Forgot PW' link, or will not login. So, clearly I can't remember the password I've put in, the next time I'll have to use it, I'll finally avoid posting an answer, and your website will loose interest/value here. Don't be stupid with your intellectual superiority, let the users take their responsibilities if they use a weak password to your point of view. - xryl669
3
[+8] [2011-05-17 13:32:54] Sklivvz

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.


I'm pretty sure #1 is how most sites on the internet work, otherwise you'd enter an email and have no idea if you entered the correct one or not. I don't support what you are proposing in Option A.. - Jeff Atwood
Registration reporting an e-mail is in use is a rather recent change, though you're 100% right that it was inconsistent. We're returning a better error message now on failed login. - Kevin Montrose
(3) @Jeff, "most sites on the internet" are insecure... This is well known as a class of vulnerability that @Sklivvz points out here, this can assist an attacker in various bruteforcing schemes. For example, PCI-DSS (though not my preferred guidance) specifically forbids this. - AviD
@jef: Option C, introduce a CAPTCHA for password recovery as it prevents brute-forcing it. It will still leave the vulnerability for specific emails, but at least it would prevent validation of large lists of possible user names. - Sklivvz
@Sklivvz, CAPTCHA does not prevent brute-forcing, it only makes it a bit (a very little bit) harder. If there is enough value being guarded by the CAPTCHA, it would barely slow down professional / criminal brute-forcing. (That's not to say it has no value here, just a little, and that should be carefully analyzed before jumping in.) - AviD
@Avid. It makes it much slower and/or costly and/or computationally intensive, so possibly infeasible. That said, if you assume infinite capacity, there's no difference. For all practical purposes, it makes you annoying enough that hackers go look for a different target. - Sklivvz
@Sklivvz, not much slower, and not very costly. Computationally intensive can be made irrelevant... At ~50 cents for 1000 CAPTCHAs, its pretty darn cheap to just buy your way into those large lists of users... For hackers, this is not really that annoying (okay, cheap is more expensive than free, but still...); but it is more annoying for the users than the hackers. - AviD
@Sklivvz also see my (correct, though not accepted) answers on SO: here and here, and also this question on ITsec. - AviD
@Avid, any security system is fundamentally unsafe (unless it's turned off). Security is about trading off feasibility with risk. If you read my answer and comments, I propose alternatives with different trade offs. It's up to Jeff to choose which trade-off correspond to his vision. You are arguing against a statement I never made (that using captcha would make the site secure). I merely proposed it as a possible trade-off. - Sklivvz
@Sklivvz, oh I completely agree, no need to quote myself back at me :). I was arguing against a statement you did make, namely "... a CAPTCHA for password recovery as it prevents brute-forcing it". I was simply pointing out that it does not do that. - AviD
4
[+7] [2011-05-18 10:03:25] Sklivvz

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


(1) +1, reminds me of Douglas Coupland - davidsleeps
5
[+6] [2011-05-21 09:17:16] M'vy

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)

Edit

Argh... and if you forgot to put httpS your denied too... even if you are login on the HTTPS version of the site.

Edit

At the end sourceforge refused it ... Could not verify your OpenID. Please try again.


Thanks for the report. SourceForge appears to be doing something very wrong here (though the OpenID spec is... more of a set of guidelines, so maybe they're doing it right; who knows). However, this seems to be a pretty common mistake; I've added some code to correct for it, and you should be able to add openid.se now (using http or https, and openid.stackexchange.com or stackexchange.com). - Kevin Montrose
Thank you @Kevin :D - M'vy
I confirm it's working very well. - M'vy
6
[+3] [2011-05-22 05:47:48] Aleadam

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)


(1) We intentionally don't disable form submission. In our experience that confuses more users than an error message; they get "locked into" an error state rather than being given additional instruction, basically. So, its by-design. Thanks for testing though. - Kevin Montrose
(1) @Kevin I did not really know if it was intentional or not, I just reported it... but now there is a new, more important problem. See the updated post. - Aleadam
Glad you liked the password reser joke :) note that those are real popular passwords too! - Jeff Atwood
7
[+2] [2011-05-18 10:12:47] Sklivvz

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.

enter image description here


8
[+1] [2011-05-24 01:10:45] Complicated see bio

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.


Possible bug? When I'm in this web page, the plus symbol in my eMail address appears as a space: openid.stackexchange.com/user/edit - Complicated see bio
9
[0] [2011-05-29 13:10:27] Pekka's Organic Rep Farm

The signup dialog has an iframe border in IE8:

enter image description here


10