What are your thoughts about this issue in regards to an e-commerce environment?
Do you think it is wise to turn autocomplete off on all sensitive input fields such as passwords (for log-in areas), or will this just inconvenience the client?
I hate websites that do that. It is the client's decision if they want to save passwords or not. What is particularly irksome is that this attribute breaks OS X's native KeyChain support. So, even though the user has stored his password in a secure file, and authorized themselves and the application to use it, the website still thinks it knows better. Just plain annoying.
An eCommerce application I worked on several years ago underwent a security audit and one of their recommendations was to disable autocomplete for sensitive fields.
It wasn't a strict requirement, but it probably will be at some point, given how eCommerce standards are these days..
Unless it is a highly-secure site, I would tend to leave autocomplete on. If it is for a password field, the browser will prompt the user if they want to save the information, at which point the user can make their own decision.
I really dislike that when I start to type in my credit card number and it lists all of the numbers I have used in the past, as well as the 3 digit code. Not cool IMO.
It depends what you mean by e-commerce. In Internet banking you should disable autocomplete. In online shopping - not necessarily.
It's worth remembering that autocomplete does not force remembering passwords. User has to agree to store their credentials, so they always can reject.
I concur. By habit, I leave autocomplete on. However, there was a project for the air force I was working on that had a requirement to disble autocomplete. Really depends on your requirements.
I actually don't think i've ever seen "autocomplete" work on a password field.
Autocomplete(when you start typing something in a form field, and the browser popups up a list of suggestions), and asking the browser to remember your user name and password are two different things.
If you're talking about the browser feature that remembers your username and password, i'm not aware of a way for you to disable that on the user's machine.
I use password/form managers like 1Password and RoboForm specifically to get around websites that disable autocomplete; these add-ons typically ignore the website's preferences in favor of their own more sophisticated logic.
Most e-commerce sites disable autocomplete for credit card fields. They store and redisplay the info when an authenticated user returns, then only require the user to re-enter the CVV. This way the site gets users to sign up (otherwise, they'd have to re-enter the full CC info every time), keeps the CC info masked on subsequent visits, and only burdens the user with entering a three-digit number. (It's also a small way of building secure practice around CC numbers so users will hopefully be more protective of them.)
Keep in mind that setting autocomplete on/off only addresses confidentiality of data for shared environments, i.e. more than one person accesses the same browser. For example, if your app were intended for a classroom, then it would make more sense to disable autocomplete entirely since the app will be re-used in the same browser by many different people.
Consider it an (in)convenience feature, not a security feature. You can't protect users from every dumb mistake when sharing browsers (like not logging out) and, to be nicer to dumb users, it won't have any bearing on client-side attacks like keyloggers. If the shared environment isn't secure, then your app can't do much to protect its users.
Related
In a recent project I put a captcha test on a login form, in order to stop possible brute force attacks.
The immediate reaction of other coworkers was a request to remove it, saying that it was inapropiate for that purpose, and that it was quite exotic to see a captcha in that place.
I've seen captcha images on signup, contact, password recovery forms, etc. So I personally don't see inapropiate to put a captcha also on a place like that. Well, it obviously burns down usability a little bit, but it's a matter of time and getting used to it.
With the lack of a captcha test, one would have to put some sort of blacklist / account locking mechanism, which also has some drawbacks.
Is it a good choice for you? Am I getting somewhat captcha-aholic and need some sort of group therapy?
Thanks in advance.
Just add a CAPTCHA test for cases when there have been failed login attempts for a given user. This is what lots of websites currently do (all popular email services for instance) and is much less invasive.
Yet it completely thwarts brute force attacks, as long as the attacker cannot break your CAPTCHA.
It's not immoral per se. It's bad usability.
Consider security implications: the users will consider logging in to be time consuming and will:
be less likely to use your system at all
never log out of your system and leave open sessions unattended.
Consider other forms of brute-force attack detection and prevention.
Captcha isn't a very traditional choice in login forms. The traditional protection against brute force attacks seems to be account locking. As you said, it has it's drawbacks, for example, if your application is vulnerable to account enumeration, then an attacker could easily perform a denial of service attack.
I would tend to agree with your co-workers. A captcha can be necessary on forms where you do not have to be authorized to submit data, because otherwise spambots will bomb them, but I fail to see what kind of abuse you are preventing by adding the captcha to a login form?
A captcha does not provide any form of securtiy, the way your other options, like the blacklist, would. It just verifies that the user is a human being, and hopefully the username/password fields would verify that.
If you want to prevent bruteforce attacks, then almost any other form of protection would be more usefull - throtteling the requests if there is too many, or banning IPs if the enter wrong passwords too many times, for instance.
Also, I think you are underestimating the impact on usability. A lot of browsers provide a lot of utilities to deal with username/password forms and all of these utilities are rendered useless if you add a captcha.
I would like to address the question in the title—the question of morality.
I would consider a captcha immoral under the following circumstances:
It excludes participation in the application to those with physical or mental challenges, when the main portion and purpose of the application would otherwise not make such an exclusion.
The mechanism of the captcha exposes users to distressing language or images beyond what would normally be expected in the application.
The captcha mechanism as presented to the user is deceptive or misleading in some way.
A captcha may also be considered immoral if its intent is to exclude genuinely sentient machine intelligences from participation for reasons of prejudice against non-humans. Of course, technology has not yet advanced to the level at which this is an issue, and, further, when it does become an issue, I expect human-excluding gates will be more feasible and common.
Many popular (most used) mail server doesn't have it?!
The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).
I'm wondering what people use for storing their username, passwords, urls, IPs, domains, and any other login information they need to both do their job and in general life. It might also store serial numbers or similar data.
I find that I'm registering for probably 5 sites a month, paying some piece of software, just setting up a new hosting account or ssh access to something. By the end of the month, I've both forgot what those sites were and what my username and/or password is--not that I use a completely different password every time. Next month when I go back, I end up using the forgot password and then changing the password to something that I'll forget.
I'm also thinking it needs to be mobile, probably browser based (not a USB key or other protable media) and very secure.
I'm thinking there are maybe 2 different solutions: one for a company where everyone in the company can access it and one where it's only you.
What does everyone else use to store their authentication information?
Edit: I'm looking for something to store more than just a username and password. It needs to store IPs or domains for example for SSH access. It also needs to have the ability to put some kind of comment in or other information because, for example, the site maybe limited to 1 IP.
I use KeePass. It has versions for various platforms (KeePassX for Linux, for example) and has been quite stable for me. No lost data yet, so I haven't had to resort to my backups :)
I use PasswordMaker and it's fantastic Mozilla Firefox add-on. All passwords are generated from a website URL and your username. You enter a master password which then essentially "unlocks" all your passwords so you really only have to remember one password but can have a unique password for each website you have an account on.
PasswordMaker was also recommended by Jim McKeeth in Stack Overflow Podcast #9.
Note also that there are many other ways to integrate with PasswordMaker besides the Firefox add-on. For example, they have an online version that can be used essentially anywhere as long.
I use a certain string of characters in all my passwords, then for each new site I register on I append another string of characters which can be determined by looking at the site's name or URL. All I have to remember is the base password and the algorithm for determining the rest of the password.
Try Password Gorilla and use GetDropBox.com to keep it synced across machines. I think it was recommended by the developers of this site.
I keep everything always with me on my Treo, with SplashId. (Handles custom fields, too)
I have two different solutions:
For work related passwords (login to our webbservers and mysql users and logins), we use a shared google doc. It's not ideal, but it's better than having just one password (we did when I started), and it's better than being locked out if one guy gets run over by a bus.
My private solution is a variant of Jeremy Rutens solution, an algo that gives a couple of chars based on the url/hostname and another algo for the second half of the password (which usually gives me two or three choices when I've forgotten the pass - but that takes just a few minutes extra).
Here's a simple solution that I think fits your requirements.
Store all your usernames, passwords, URLs, IPs, whatever in a plain text file. Yes, really. You may even want to have one text file for usernames & passwords, another for URLs, another for IPs ... whatever works for you.
Alternatively, if you'll have MS Office, Open Office, Star Office, or some other compatible office program available at every site, a spreadsheet works splendidly for this type of thing.
Zip this (these) file(s) up and apply a good password.
Attach this zip file to an e-mail you keep in your favorite Web-based e-mail box. To keep it easy to find, you might want to create a separate folder, or just create a separate e-mail account just for this purpose.
That's it. Assuming you can rely on have a Web browser with access to your Web mail, an unzip utility, and a text file reader (or better yet, spreadsheet reader), you can access your information securely from anywhere.
I use Password Safe. You can store, organize and retrieve all the essentials in a snap. It also has a handy "generate random password" that I use more and more, especially for those once-in-a-while-never-worth-remembering-the-password sites.
http://passwordsafe.sourceforge.net/
I store my passwords in text files on an encrypted partition.
Like claudiu I use a several tier system and my memory, I have a good handful of passwords that I know all from memory, and depending on what type of stuff I'm using depends on what passwords I use. Effectively I have two or three passwords for each of my "tier" catagories. Sometimes I have to try several of them if it's a site I don't use often until I get in. Though typically I'm very good at remembering which one's I uses on which sites.
Clipperz looks like a good solution. It allows you to store pretty much anything you want and encrypts all of your data with your password. It also includes an export feature and offline read-only version. And it's free!
Keepassc (https://github.com/raymontag/keepassc) on my Linux machines, with the database file stored within Dropbox so it can be synced with my Android phone (KeepassDroid) and Windows machines (Keepass). Works great!
Use the same password for everything. Give it out to strangers.
Just kidding. I use three tiers of passwords - the lowest one is really easy to remember, and applies to all accounts whose security I don't care about. I just use it for most things like this.
For the other stuff, I don't find it to be such sensitive information, so I'll store them in a large "info.txt" text file. I'll put a password hint next to it, such as "the bad one", or "double z" for example, if I have a password I use a lot that has two zs in it. I just use standard CTRL+F search to lookup the info.
I have a public-facing website that is used to manage business infrastructure equipment for my clients. A security breach on this website could cause expensive problems for clients.
A number of different websites--mostly banks, health care, and government--disable the "save password" dialog from appearing in Firefox, IE, and other browsers citing security concerns. I'm talking about the box/bar that appears after you enter your login information, so the browser can auto-populate the username/password fields for you the next time your visit that site.
My question is not how to disable, because that is answered in the Disable browser 'Save Password' functionality question.
What I want to know is:
What are some cases in which it is absolutely essential to disable "save password" functionality? Do such cases exist?
Does this technique really provide any additional security? In other words, won't people find a way to leak their passwords despite your best efforts?
Do users complain about removal of "save password" functionality?
Any other thoughts on when to disable "save password" functionality?
I complain about it ;-) I was actually just thinking about this today because my online banking site disables password autocompletion and it's really irritating.
While not a majority of computer users, there are plenty of people who know how to manage their passwords securely, and for them it's really irritating when websites disable the password field autocompletion because it means they need to do something like, say, writing the password down, or picking a simple one that's easy to remember - neither of which makes them happy, because as I said, these are people who take password security seriously. Using a browser's password manager is pretty much the best compromise between security and convenience we have. And the annoying part is, if a website tries to disable autocompletion there's no easy way to tell some browsers to ignore that. (In Firefox it requires hacking some Javascript file)
This also ties into the thing Joel once wrote about how users, erm, people like to be in control of their environment. They're much less likely to use (or at least like) a program or website that takes it upon itself to decide that they can't be trusted with a password manager.
Question is, in what cases does it help when you don't allow saving passwords
Someone breaks into your home, gets access to your PC, visits the site and now has access - uhm, somehow abstract idea
You loose your Notebook/Netbook, someone finds it, cracks your password (hopefully you have one in your Whateverbook), browses to the site and has access
Both are more by chance than anything else. Someone who wants to get access to an account will use spyware like keylogger. But when there is a keylogger on your PC, disabling the save-password-feature would'n help anything.
Do users complain about removal of "save password" functionality?
Yes, absolutely. Users never like it to be domineed.
You need to do some basic risk assessment :
How critical your application is?
If it's an online banking application risking a client loosing their investments because they used a public computer or their notebook nicked, this is not a good idea, so disable it.
Security vs. Usability is not an easy battle you need to do some sacrifices. But also if you've got two factor authentication you might not disable it because only that password wouldn't be enough to transfer money or doing other dodgy stuff.
How frequently used?
If this is a web-mail or a service like twitter just enable it. Otherwise you'll piss off so many people.
I don't like web sites those disable it, because I know what to save, what not to save and the risk I'm taking. However normal users wouldn't, therefore you should do the hard decision for them.
Also there are other non-obvious risks you need to consider:
Publicly used computers
Old HDDs in Ebay
After an exploitation all attackers will look this data first, because they know it's a good loot.
There have been client-side attacks / weakness released only focused on auto-completed passwords and usernames.
1) "What are some cases in which it is absolutely essential to disable "save password" functionality? Do such cases exist?"
There is no well defined general rule as such. It totally depends on the the kind of services that are provided to the user and their relative importance. For example, net banking web sites have this functionality disabled whereas a normal web-based email site or a online discussion forum would rather leave the save password feature tuned on. It all depends on what you are offering to the user and it's relative importance.
2) "Does this technique really provide any additional security? In other words, won't people find a way to leak their passwords despite your best efforts?"
Yes. This technique at least blocks off one possible way of password stealth. But, it does not guarantee no password stealth in any sense. From the most trivial ways of password stealth, to keyloggers that capture key strokes, to even bruteforce mechanisms or to even phishing sites that resemble your web site, the routes of password stealth still remain open. You are just blocking off one of the ways thats it.
3) Do users complain about removal of "save password" functionality?
Depends on the user really. Some who realise the the importance of the save password feature being disabled would not complain about it anyway. And those who are just lazy to re-enter the credentials everytime should not be worried about. Afterall, user security is privacy is much more important than user frustration because we are dealing with important data here and we disable the save password feature for the good of the user only.
4) Any other thoughts on when to disable "save password" functionality?
This again is like question 1). It all depends on the importance and the aftermath/cost to pay of loosing the password.
I would never disable password saving. You are just as likely to increase the risk as to decrease it. Example:
User logs into your website for the first time, and manually enters their password
User visits a malicious site, which installs a keylogger
User visits your site again, enters the password again, keylogger sends user's password to the thief.
If the user had saved their password instead, they would not have had to type it again in step 3, and so the keylogger could not have been used to steal it.
I've just run into this from the other end (having to disable the "save password" functionality) and for us, it's an audit issue. Some audit frameworks view this as a security issue (person A has certain rights into an application [web-based], they save their credentials into the browser, person B gets into the application using person A's account because person A walked away from their computer without locking it).
This isn't to say that there should be other controls in place (forcing Windows to lock, etc), but that there are sometimes "valid" reasons for why some websites don't allow you to save your password.
All these answers are about protecting user data. I'm currently working on a site where the sensitive data is on the other side - the provider, for a fee, gives access to this data and wants to make sure that nobody except those paying are accessing it.
Obviously the users in this case may not be as careful as they would if the data were theirs.
And so we try to disable the save password functionality.
I know that especially in the US, bank security is lax. Bank sites shouldn't even use password protection, as it completely fails to protect against even simple keyloggers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
OpenID is a great idea in principle, but the UI and the explanation as to why it is good are currently not tailored for general use -- what do you think it would take to make OpenID work for the general public? Can this be solved with technology, or is the problem so intrinsically hard that we are stuck with difficult explanations/multi-step registration procedures, numerous accounts, or poor security?
It needs to be much simpler: involve less knowledge of the concepts, and require fewer steps - preferably zero. When the technology works with little or no assistance, it'll take off.
The mechanics of OpenID credentials, providers and suppliers shouldn't need to be exposed to the user. People talk about educating the masses of internet users, but that's never going to happen - the masses never stop being stupid. If you want to appeal to the masses, you need to bring the technology down to meet their level instead. When a Google-affiliated site picks up that you're logged into Google and silently uses that account, it works without you ever having to tell it who you are. The fact that OpenID is so clumsy in comparison is why the big providers like Google are still avoiding it, and why the general public won't adopt it.
I think the developers of OpenID messed up when they used a URL rather than an email address for the IDs. People know what email addresses are, they already have one that's associated with them (or can get one easily), and email providers like Google and Microsoft are happy to adopt a role as portals. In fact, an automatic translation from email address to URL is all it would take:
myname#example.com -> http://www.example.com/openid/myname
I think it'll take a huge buy-in from a site that millions of people use; for example, MySpace is soon supporting OpenID, so now the number of users that OpenID supports has just jumped by a huge amount. If more of the high activity sites on the net follow this lead, there you go!
ISPs should provide openIds to all their customers that mimic their e-mail addresses. Perhaps openID needs to support automatic translation of foo#example.com into http://openid.example.com/foo so that ISPs can easily set this up on a separate server.
It will take all the popular sites supporting it and making it transparent to the user.
"You can make a useraccount here, or if you use MySpace, Google Mail, Hotmail, etc then you can sign in using OpenID."
Don't sell it as a new service, sell it as being able to sign in using a different ID from another site.
The issue, however, is that with everyone supporting it each user will now have a myspace id, google id, etc. Now if they sign onto stackoverflow with their myspace id then later with google they may be perplexed that stackoverflow doesn't recognize them.
I wonder if openid has a solution for linking openid accounts so they are one and the same - I doubt the technology allows for it, since they are essentially independant signing authorities. Google would have to share data with Myspace and vice versa to enable that...
I don't think it will become mainstream. I think Ted Dziuba gets it right when he says it solves a "problem" that most people don't consider to be worth solving.
http://teddziuba.com/2008/09/openid-is-why-i-hate-the-inter.html
It will have to get a hell of a lot simpler, with easier-to-remember IDs.
You mean it isn't already? ;)
Obviously a lot of currently-popular applications would need to offer it and make it obvious that it was a good alternative.
If Google and Facebook made it an obvious option, that would help.
Ultimately, user education will really be the thing that does it. I doubt most people would care though...dumb sheeple.
Many of the responses so far seem to boil down to two options:
user education, and
forcing adoption (lots of sites changing to openid from in-house auth.)
Is that all we can do? What about distributed tools to make it easy for casual users to do openid delegation? (Say, something integrated with OS X / Windows / Ubuntu) Are there technological barriers that make this infeasible?
If client-side (and vendor-issued) applications could let you manage your on-line security preference, then we'd possibly be able to combat some of the risks associated with giving random sites your passwords -- since the "login area" would be some local program sitting in your systray, or what not. Of course, the integration of web apps with the desktop (such as that provided by Chrome) may make such a distinction impossible in practice, so it may be a moot point.
In any case, it seems like there should be something we could do now to make openid more palatable to the general public, and speed adoption in addition to making the system more user friendly.
As someone who primarily programs web apps in Java, I can't/won't use OpenID because the library support isn't there. JOID and openid4java are the only two that I know of. JOID is apparently not actively maintained, not including really important patches that have been on the mailing list for months; and openid4java requires >40 megabytes of external dependencies, including some that need to go into the endorsed classpath, which is, as one user commented, ridiculous:
Comment by witichis, Apr 28, 2008
46MB download for a simple redirect and de/encryp - are you f****n' drunk?
In my opinion, OpenID is not bad. It consolidates login credentials. It does solve a real problem, while it may not be the optimal solution The only two problems I can see are that you must trust the identity provider not to allow someone else to claim to be you, and that relying parties (web sites you log in to) can collude to link your identity on multiple sites together.
I think we need to see OpenID offered as a login method more consumer oriented websites. There are a lot of big consumer sites that can be used as OpenID providers, but the only place I recall seeing OpenID available as a login before Stackoverflow is to comment on Blogger. Being a provider is great and all, but it's pretty much invisible to consumers. Seeing an actual place to use OpenID, on the other hand, will probably garner somewhat more interest.
It would certainly help if more OpenID consumers were also OpenID providers. As a developer, I'm comfortable going through a few contortions to figure out that I can create a new ID on openid.org, but the more mainstream consumer could easily be put off by the process.
The fact that big sites will accept OpenID isn't, on it's own, enough to make it mainstream. The closest I've seen so far was having LiveJournal both accept and provide OpenID authentication (which I believe it has been doing for quite some time).
But I think that just accepting OpenID isn't enough. What we really need is more sites like this one that refuse to make their own authentication system, and require OpenID authentication. If the "next big thing" said you have to use your OpenID to log in (with a really simple wizard to set up a new ID with someone else), I believe that it will start the ball properly rolling.
Browsers should auto-fill OpenID login boxes so that you don't have to remember your ID.
Web frameworks should come with it as the default, unless you take lots of extra time to configure a simple username/password combination.
Sites that use OpenID need to put it front and center on the login page. I have seen many sites hide it behind a link under the standard login/registration page like this:
Username:
Password:
or use your OpenID
Choosing a provider needs to be much simpler.
At present there's no way to know how reliable, trustworthy or secure any of them are, or which will still be around in 6 months time.
It won't be mainstream, as it's too much effort and is too confusing for those used to email address and password.
For example:
To login to stackoverflow with Opera I have to click login, select myOpenID from the list, type my username, hit enter, press Ctrl+Enter to autofill the password on the myOpenID site, then press the continue button.
To login into any normal site with Opera I just press Ctrl+Enter to autofill the saved user/pass combo.
Im looking into OpenId right now to integrate into a start up site so it can manage the login process for my site.
I think to make this main stream they need to make this super simple. Copy, paste code into your site and it loads the login form that gives you pretty much what Stackoverflow.com does.
I think you can style up the layout of the form to be more recognizable as well.
Personally I don't think it needs to be mainstream at all, it was an interesting idea, but it is no longer relevant.
When I create a normal login, I type in my username, master password and click on the SuperGenPass bookmarklet. That is it, when I had to sign up to stackoverflow I had to find an openId provider, sign up there (which took forever) login to my website and setup delegation, then add stackoverflow to my list of sites.
And yesterday I couldn't login because I had removed the file from my webhost and they had some security issue.
Conclusion: Don't use openid.
I'd use it if I could do it per-site and aggregate the identity later on my own time and terms. As it is, it's a giant pain in the ass to even find a decent OpenID provider; by decent I mean stackoverflow.com isn't one so I'm not going to bother.
Make it less open.
i do not want the same identity on multiple sites.
i do not want to have to create a flickr account before StackOverflow will let me post.
i do not have to have to create a new flickr account for each website that i want to register with.