| Intranet Applications |
Internet Applications |
|
|---|---|---|
| Private (Employees) |
Zimbra CS |
SilkRoad Aetna |
| Protected (Partners) |
n/a | Basecamp Google Docs |
| Public (Anyone) |
n/a | www.wested.org www.simscientists.com |
Varying levels of interoperability are possible:
Seamlessly logging in with OpenID requires automatic (unverified) redirection between domains.
That makes the OpenID server a 3rd party. This can cause cookies for the OpenID server to be rejected if you turn off 3rd party cookies and your browser strictly follows the Unverifiable Transactions rule in 3.3.6 of RFC2965.
An example of this is Opera. If you turn off 3rd party cookies (by setting the global to "Accept only cookies from the site I visit"), you can't log in with OpenID because the server script you submit to automatically (without your interaction to approve it) redirects you to the OpenID server and the OpenID server does the same to get you back.
But, you get lucky in Firefox, IE and Safari with their corresponding blocking of 3rd party cookies because they violate RFC2965 in multiple situations.
Having to use OpenID in this case does a disservice to more compliant clients.
As a workaround, in Opera, besides accepting all cookeis, you can goto tools -> preferences -> advanced -> Network and turn off Automatic Redirection. Then, you'll be able to verify and click each link you're redirected to and the cookies won't be rejected because the transactions are verified.
It should also work if you keep Automatic Redirection on and both servers generate a page with a link for you to click on so you can verify the transaction. But, there can't be any automatic redirects anywhere.
Logging in with just a username and password where you're only dealing with first party cookies would be much better in this case.
OpenID is still cool though and I guess Opera just needs an option to allow unverifiable transactions between SO and your OpenID server so that you can use "Accept only cookies from the sit
| Name | Ease of use | Security | Remembers information | Multiple profiles | Anti-phishing measures | Password protected |
|---|---|---|---|---|---|---|
| AOL/AIM | 3 | 4 | Yes | |||
| Blogger | 9 | 4 | Yes | |||
| ClaimID | 9 | 4 | Yes | Yes | ||
| GetOpenID | 7 | 4 | Yes | |||
| 7 | 4 | Yes | Yes | |||
| LiveJournal | 9 | 1 | Yes | |||
| MyOpenID | 8 | 9 | Yes | Yes | Yes | Yes |
| MySpace | 6 | 1 | Yes | |||
| Sxipper | 7 | 8 | Yes | Yes | Yes | Yes |
| VeriSign | 7 | 7 | Yes | Yes | Yes | |
| Vidoop | 8 | 4 | Yes | Yes | Yes | |
| WordPress | 5 | 1 | Yes | Yes | Yes | |
| Yahoo! | 10 | 4 | Yes | Yes |
Users hate them. They're a massive headache to network administrators. But IT departments often mandate them nonetheless: regularly scheduled password changes — part of a policy intended to increase computer security. Now new research proves what you've probably suspected ever since your first pop-up announcing that your password has expired and you need to create a new one. This presumed security measure is little more than a big waste of time, the Boston Globe reports.
Microsoft undertook the study to gauge how effectively frequent password changes thwart cyberattacks, and found that the advice generally doesn't make much sense, since, as the study notes, someone who obtains your password will use it immediately, not sit on it for weeks until you have a chance to change it. "That’s about as likely as a crook lifting a house key and then waiting until the lock is changed before sticking it in the door," the Globe says.