Slashdot Mirror

Because that 2FA token sends info from the website you're logging into to Google. Google knows the ID of your 2FA and now knows you are a user of that website and when you log in.

But I use them on internal systems without Internet access at all.
How exactly are you saying the token keys send anything to google?

My Yubico key, which uses the exact same protocol and backend PAM modules, I've used for years to login to a machine that not only doesn't have Internet access, but has no network access at all.

Perhaps you are just confused because for the first couple months google only sold the keys to people with google cloud accounts, not realizing they now sell them to anyone?

Or perhaps you are mistakenly thinking google invented the fido u2f protocol, and don't understand it's existed for years?

The PAM module is open source: https://developers.yubico.com/...
No networking required after you download the GIT tree.

Getting phished for the password sure - but who gives out the 2FA code?

Oh, you would be surprised how many people do... There have been plenty of attacks in the wild doing exactly that - persuading people to give out 2FA codes (from Steam Authenticator codes to banking token codes). And it is amazing how many people willingly hand them out.

Even presuming a hacked website I would think the key would just hand over the data to the fake website?

That's the beauty of U2F - the generated code depends (among others) on the actual URL. So if you get a phishing link on goog1e.com, that site will receive a totally different 2FA code, one that will NOT work on the original website.

More details here, for example.

The downside of this design is that it requires support from the browser (someone has to provide the actual URL when requesting the 2FA code), and major browser manufacturers don't seem that eager to implement it. Maybe the new WebAuthn standard will change this...

Actually, the FIDO U2F standard would not allow man-in-the-middle attacks with a spoofed website. The key will only work with the specific domain that authenticated the key, so a fake domain wouldn't work. If the website itself is hacked on the back end, then all bets are off. Same thing if the user's browser/computer is hacked.

https://www.yubico.com/2017/10...

That is the whole point. With a hardware key, you no longer type a password.

https://www.yubico.com/start/m...

Not sure if you're trolling or what, but perhaps you have no idea how yubikey works.

https://www.yubico.com/solutio...

Source: https://developers.yubico.com/...
This is something I use on a daily basis. It does indeed exist.

Don't confuse them with facts!

I've been testing the Yubico devices, they work great! I just put an order in for their new security tokens.

The fingerprint scanner was just one example of a supported device. You can use hardware tokens too.

Yubico announced their new security tokens today, they ship on the 13th.

The fingerprint scanner was just one example of a supported device. You can use hardware tokens too.

Yubico announced their new security tokens today, they ship on the 13th.

I agree that USB based 2FA that supports PKCS is better but even OTPs can be secured on the server side. Yubikey sells a HSM (hardware security module) for servers to store OTP keys on.

https://www.yubico.com/product...

Other companies sells HSMs as well but I have not evaluated which ones support OTPs specifically versus other HSM use-cases.

Many sites have apps for a smart phone which do the same thing. Otherwise you need a keychain for every site.

...or a device that supports a standard like U2F. There are at least a couple of options here; the Trezor that holds my Bitcoin stash is also currently set up as a second factor for Google and Dropbox. There's also a YubiKey that supports U2F.

It sure did, but it is limited and affects PIV and OpenPGP smart card certificates that were generated on the affected Yubikey 4 devices. Newer Yubikeys are unaffected, certificates that were generated elsewhere and then imported are also unaffected. There is a security advisory with all the details.

Here is Yubico's statement on what features of the Yubikey 4 are affected:
https://www.yubico.com/2017/10...

I'm amazed that people are all mad about the stock sales and everything. I mean, yes, that's illegal, but we have bigger problems--which we can fix (YouTube).

You can get a credit card or open up a car loan? You can afford $18. I wish the Neo would go Gen 4 with USB-C already; I'll probably settle for a 4C.

Can Microsoft please PLEASE fucking fix PIN Number caching finally!? Yubikeys are fucking worthless ever since a March Windows Update broke them. It has been a serious pain in the ass on Windows 10 machines to have to RDP into a Win7 machine just to be able to authenticate with servers, Git, and SSH in general. https://forum.yubico.com/viewt...

but something that is secure and doesn't make your CA the easiest way to take over the whole IT

You keep the root CA off line for this reason. It could be a VM - nothing fancy. If there is a breach you revoke the certs and breathe easy.

but if you know an easy way a at best semi-competent (i.e. no trying to run a company CA) Windows admin can implement smart-card support for Windows I'd be interested.

While CAs are very complicated setting one up isn't as hard as you think. In fact SBS (or whatever it's called now) sets one up by default. If they compromise your CA -- well, they've already compromised your domain controller and main server so it's moot.

You might look at Yubikey - they are pretty cheap, do not require a PIV reader (looks like a USBkey) and can act as a smart card - if you're running a CA. If not, they can run in stand alone mode to require 2FA for local Windows login - maybe more of what you are looking for?

https://www.yubico.com/why-yubico/for-businesses/computer-login/windows-login/

Ubikeys look like secuity dongles, but present themeselves as keyboards so instead of retyping a long one-time-key, you just press a button and it "types" it for you. All without needing OS specific drivers. But they doen't look like a keyboard.

KeePass, or any other offline password manager, is a good first step. I really shouldn't need to go into the inherent issues with using an online password management system. However, to improve the security of the database, go with two-factor authentication by adding plugins such as OtpKeyProv and configuring KeePass to use it in conjunction with a Yubikey token.

(Disclaimer: I am not associated with either the OtpKeyProv developer or with Yubico. I use them as examples based on past successes.)

https://www.yubico.com/2016/05...

While I appreciate what you say, got a better idea? You have to trust someone somewhere, would you rather pay 10x the amount for a Gemalto solution which does the same thing but none of it is open source?

https://www.yubico.com/ - Yubico, the makers of Yubikeys, is the primary company and primary devices that Google, Facebook, Github, Dropbox, and others use. Reading the various comments here on Slashdot, I just want to quickly clear a few things up. Some think this is just a theoretical API. No, it is fully implemented, and the hardware has been on the market. I've been using my Yubikey for over a year now. The thing is fucking amazing. The key supports several different modes, so let's go through a few of them really quick to clear up concerns from above.

The type of authentication mentioned in TFA works by plugging in the USB key. After that, the browser makes a request to the key. The key then has an LED that starts blinking to indicate said request. The key does *NOT* process the request until the button on the key is pressed. The encryption key stored on the physical key also can NOT be read off of it at all, the device handles processing of the initial request. (yes, admittedly, this is slower than a normal CPU, it takes 1-2 seconds to process)

There are other modes, too. There is a mode which works exactly like Google Authenticator, where you can register 2-factor codes with it. The generated time based codes can then be read back either by USB or by NFC on a phone/tablet. This has the added advantage of the fact the seed for the time code is not retrievable from the device. The only thing the device will transmit out is the calculated time-based code. This has an advantage over Google Authenticator, where a compromised phone could easily leak the seed values and generate new time based codes. This calculation instead happens on the key, and only the final result is returned instead.

This device also works with PuTTY for SSH authentication. This is by *FAR* my most favorite feature. TortouseGit on windows also uses PuTTY for authentication, so this includes source code. You can pull out the public key from the device, and use the device to authenticate yourself anywhere that supprts SSH. I personally use this to authenticate into a cluster of servers that I manage.

This device includes a static password, too. Not everything supports these newer modes. There are a couple services that I use which dont. A randomized password up to 32 characters can be stored on the device, and with a single press of the button will emulate a keyboard and type it in. This is much MUCH easier than trying to type in long complex passwords which use tons of extended characters. But again, this caps at only 2 passwords (the device has 2 "slots" total, and other things such as the method mentioned in the article takes up 1 of those slots as well)

But pretty much every concern I've seen in the comments on this page are all directly addressedon the Yubico web site. These guys have thought of pretty much thought of every possible scenario imaginable. This isn't just some weekend project. This is a serious security product help designed and implemented by some of the largest tech firms in the world who have a serious stake at securing their own networks. The price for the keys are really not bad, so yeah, I'd personally recommend them.

Look at this U2F NFC fob.

Linux? Yes!

I use these on Linux, MACOS and Windows for all my Github and Google accounts.

https://www.yubico.com/github-...

See the FIDO U2F Security Key.

"Security/privacy is not exactly a priority at facebook." [Citation Needed]

https://www.yubico.com/2013/10...

In case anyone missed it, if you're using one for OpenPGP key use you might be vulnerable to a pin bypass attack. Details on how to check are on that page.

If you have a vulnerable device, YubiCo will send you a free replacement upon request - just open a ticket with your serial and order numbers.

In case anyone missed it, if you're using one for OpenPGP key use you might be vulnerable to a pin bypass attack. Details on how to check are on that page.

If you have a vulnerable device, YubiCo will send you a free replacement upon request - just open a ticket with your serial and order numbers.

The Yubikey can serve as a One-Time-Password(OTP), Universal Second Factor (U2F) Authentication, Etc. I primarily use it for the U2F, which is similar to an RSA Token, but it conveniently eliminates token expiration anxiety, and errors frequently caused by chronic butterfingers. I just jam it into a USB port, it gets recognized as a keyboard, I press the little light on the top, and boom!

The NEO is similar to the standard blue Yubikey, additionally supporting NFC for some protocols. Unfortunately, U2F is NOT supported through the embedded NFC chip. https://www.yubico.com/product...

When I bought mine, I was hoping to use it as a physical password on my smartphone, simply swiping across the back side, as available with the OTP protocol. I later found out that would be forced to use the USB on everything, and have yet to find any use for the NFC with U2F. (my fault for not reading the documentation more thoroughly, as they clearly state: "...current U2F standards do not support NFC for mobile devices.")

Long story short, if you only need the U2F, don't bother with the NEO. just get the cheaper FIDO U2F SPECIAL SECURITY KEY https://www.yubico.com/product...
As far as durability, its survived me for about a year now, and I'm not known being gentile.

The Yubikey can serve as a One-Time-Password(OTP), Universal Second Factor (U2F) Authentication, Etc. I primarily use it for the U2F, which is similar to an RSA Token, but it conveniently eliminates token expiration anxiety, and errors frequently caused by chronic butterfingers. I just jam it into a USB port, it gets recognized as a keyboard, I press the little light on the top, and boom!

The NEO is similar to the standard blue Yubikey, additionally supporting NFC for some protocols. Unfortunately, U2F is NOT supported through the embedded NFC chip. https://www.yubico.com/product...

When I bought mine, I was hoping to use it as a physical password on my smartphone, simply swiping across the back side, as available with the OTP protocol. I later found out that would be forced to use the USB on everything, and have yet to find any use for the NFC with U2F. (my fault for not reading the documentation more thoroughly, as they clearly state: "...current U2F standards do not support NFC for mobile devices.")

Long story short, if you only need the U2F, don't bother with the NEO. just get the cheaper FIDO U2F SPECIAL SECURITY KEY https://www.yubico.com/product...
As far as durability, its survived me for about a year now, and I'm not known being gentile.

Here's an example in commercial marketing:

https://www.yubico.com/product...

How cheap is "cheap"?

We have VPNs to each data centre and client site and administer them over SSH generally. Some systems (eg ones dealing with customer details like credit cards) we have a single external facing host with Yubikey authentication to reach that network, and we use SSH port tunnelling to reach other hosts.

I have a Yubikey that I use for encrypting my password stores (using the private id as one of several components passed to a pbkdf). It detects replays by verifying that every token has a larger counter then all prior used tokens (and the timer depending on the application).
A Yubikey token looks like 'ficrtvulktgnerhddigbhcudufurijghfcckvchhjfli' and is a modhex (16 chars picked for being the same across charsets) and contains the following:
1) A public ID to identify the key
2) AES128 encrypted 128 bits containing the following:
a. Secret ID
b. Insertion counter (how many times its been plugged into a computer)
c. Token counter (within one insertion)
d. Timestamp (A counter counting the time since the token was inserted into the computer)
e. Random number
f. Checksum of the above
Their website has full specifications and documentation.

Yubikey is a USB OTP generator, it can be integrated quite easily and it has ssh and a little fast dig up I found this link about yubikey and openvpn..

http://www.yubico.com/applicat...
http://forum.yubico.com/viewto...

Yubikey is a USB OTP generator, it can be integrated quite easily and it has ssh and a little fast dig up I found this link about yubikey and openvpn..

http://www.yubico.com/applicat...
http://forum.yubico.com/viewto...

You can buy a YubiKey to do this today without any finicking with a Raspberry Pi. There are a few modes depending on the devices you buy. First is what you say -- it can emulate a keyboard, and input a password for you whenever you press a button on the device. It can also perform HOTP/TOTP authentication, and some of them can act as a legitimate security token that integrates with your platform's crypto.

You mean like the Yubikey?
http://www.yubico.com/products/yubikey-hardware/yubikey/

Don't forget: you can still encrypt with a keyfile you keep on a microSD card in your wallet. [copy to a USB stick in a lockbox, in case you lose it or get robbed.] Then, they can have your key, they still need the file.

Better. Use a gpg-encrypted keyfile as with loop-aes. You only need to remember the passphrase for the gpg-encrypted keyfile.

You mean like the Yubikey?
http://www.yubico.com/products/yubikey-hardware/yubikey/

Don't forget: you can still encrypt with a keyfile you keep on a microSD card in your wallet. [copy to a USB stick in a lockbox, in case you lose it or get robbed.] Then, they can have your key, they still need the file.

It must be annoying to have a smart card reader glued to your phone though.

There are alternatives to physical smart card readers, such as little Yubikey nano-style USB token "stubs", that provide a hardware authentication token integrated with a USB or micro-usb connector --- with little or no footprint outside the USB connector of the smart phone or laptop.

Only a complete and utter moron would buy from them after this.

Remember how the RSA SecureID authentication system was hacked?

Now, the way you do these tokens is to have a counter or timer inside them that's synchronized with an external system. You simply encrypt the counter and that's your verifiable ID code. The server can authenticate a couple counts in the past or present to give a wider window, and updates if drift is detected to stay in sych.

There's a concept in security called "single point of failure" that all competent security researchers are aware of and attempt to avoid, but RSA didn't. They didn't let you seed your own SecureIDs. Instead, they seeded them. In this way you had to rely on RSA to authenticate the tokens for you, instead of let you run your own server. So, this immediately raises several red flags for a security aware person: Denial of Service == All your cards stop authenticating at RSA's whim. Additionally, RSA can grant access to other people, say the NSA, by seeding a SecureID with a duplicate of yours. Furthermore, if RSA is compromised then everyone who uses SecureID is at risk, they've made themselves a single point of failure.

A better approach is to allow businesses to seed your security cards yourself, and run your own servers. This way there's no single point of failure for the entire card system -- Compromise one business doesn't leak to others. You don't have to rely on external servers for validation so even if all external lines are cut, your intranet can still validate cards. And you don't have to worry about the NSA compromising the folks you bought the cards from after you purchased them -- Only your systems know the authentication codes -- The crackers have to crack your database.

It wasn't surprising to me that RSA would get compromised because they were the single point of failure, it was only a matter of time (if not pre-compromised from inception). It wasn't surprising at all when defense related companies like Lockheed Martin and L-3 Communications were compromised thanks to RSA's SecureID breech.

Now, given the ineptitude you'd have to have as a team of premier security researchers to screw the pooch this badly in the design of your security product, and given how asinine it would be to select the absolute worst and slowest random number generator as the default for your BSafe security product, knowing you have many embedded platform use-cases, and given that it was known well in advance that trusting the PRNG was ill advised... Then considering Snowden leaks info explaining that the NSA was paying RSA to botch and weaken their security systems. Yeah, that makes perfect sense.

Given a gag order I'd understand RSA keeping quiet on this. If they cared about security of their customers then at that point we'd see RSA engineering a completely new line of security products with a goal to put our minds at ease, and inexplicably discontinue their past offerings. However, since they opened their fool mouths and claimed not to be screwing up everything on purpose... At least if they were forced to mess things up this bad I could understand, and once the spying apparatus has been dismantled I'd consider RSA still viable. However, if the NSA wasn't paying RSA to botch their security systems, then they can never be trusted again.

I use YubiKey instead. I can run my own server, install my own codes in the tokens, or let yubico do it if the application doesn't require such security. The protocol and server source code is open. I hear Google's partnering with them too.

Sad, really. Now anything RSA has touched I'm distancing myself from.

Only a complete and utter moron would buy from them after this.

Remember how the RSA SecureID authentication system was hacked?

Now, the way you do these tokens is to have a counter or timer inside them that's synchronized with an external system. You simply encrypt the counter and that's your verifiable ID code. The server can authenticate a couple counts in the past or present to give a wider window, and updates if drift is detected to stay in sych.

There's a concept in security called "single point of failure" that all competent security researchers are aware of and attempt to avoid, but RSA didn't. They didn't let you seed your own SecureIDs. Instead, they seeded them. In this way you had to rely on RSA to authenticate the tokens for you, instead of let you run your own server. So, this immediately raises several red flags for a security aware person: Denial of Service == All your cards stop authenticating at RSA's whim. Additionally, RSA can grant access to other people, say the NSA, by seeding a SecureID with a duplicate of yours. Furthermore, if RSA is compromised then everyone who uses SecureID is at risk, they've made themselves a single point of failure.

A better approach is to allow businesses to seed your security cards yourself, and run your own servers. This way there's no single point of failure for the entire card system -- Compromise one business doesn't leak to others. You don't have to rely on external servers for validation so even if all external lines are cut, your intranet can still validate cards. And you don't have to worry about the NSA compromising the folks you bought the cards from after you purchased them -- Only your systems know the authentication codes -- The crackers have to crack your database.

It wasn't surprising to me that RSA would get compromised because they were the single point of failure, it was only a matter of time (if not pre-compromised from inception). It wasn't surprising at all when defense related companies like Lockheed Martin and L-3 Communications were compromised thanks to RSA's SecureID breech.

Now, given the ineptitude you'd have to have as a team of premier security researchers to screw the pooch this badly in the design of your security product, and given how asinine it would be to select the absolute worst and slowest random number generator as the default for your BSafe security product, knowing you have many embedded platform use-cases, and given that it was known well in advance that trusting the PRNG was ill advised... Then considering Snowden leaks info explaining that the NSA was paying RSA to botch and weaken their security systems. Yeah, that makes perfect sense.

Given a gag order I'd understand RSA keeping quiet on this. If they cared about security of their customers then at that point we'd see RSA engineering a completely new line of security products with a goal to put our minds at ease, and inexplicably discontinue their past offerings. However, since they opened their fool mouths and claimed not to be screwing up everything on purpose... At least if they were forced to mess things up this bad I could understand, and once the spying apparatus has been dismantled I'd consider RSA still viable. However, if the NSA wasn't paying RSA to botch their security systems, then they can never be trusted again.

I use YubiKey instead. I can run my own server, install my own codes in the tokens, or let yubico do it if the application doesn't require such security. The protocol and server source code is open. I hear Google's partnering with them too.

Sad, really. Now anything RSA has touched I'm distancing myself from.

I haven't seen a prototype, but a really hot technology that would fit perfectly with a watch device is two factor authentication (2FA) with one time passwords (OTP), combined with NFC, and probably some biometric stuff too.
Use it to lock or unlock your phone, tablet, pc, to encrypt your devices, and really good password management and internet authentication and secure connections. Could be used to boost credit card and on-line banking security significantly. It wouldn't matter any more if a hacker stole your password from either your pc or from a web service break in; they can't abuse the password without the iWatch too.

Look at Ubikey for a 2FA, OTP, NFC usb device:
http://www.yubico.com/products/yubikey-hardware/yubikey/

Could be integrated with your car or house lock system too, or your house lighting system.

Since it could work as a broadcasting tracking device, high end boutiques could use it to dispatch grovelling salespersons directly at the iWatch wearer when they entered the premises:-)

This is slightly offtopic, but I want to promote the use of two-factor authentication. I just ordered a Yubikey for $25. It reportedly is supported by gmail, fastmail, lastpass among others: http://www.yubico.com/

Yubikeys are sort of like this. You have a usb key that has a button on it, and when you push the button it basically types in a long keyphrase which can be validated against a server running their software (they also have a free one for people who buy a key off them). Offline challenge/response is also implemented (though slightly differently).

And most of the stuff related to these things is open source too.

I have just got to plug LastPass. Decided to give lastpass a try and already it's been incredibly helpful.

You can Google Authenticator, grid multifactor, fingerprint, card reader, and yubikeys. You can customize when you need your masterkey, you can limit login to specific countries, have multiple form fill profiles, etc. A few features require premium for $12/year, such as yubikey, mobile apps, and better support.

But seriously, check it out.

I should introduce my mom to it.

RSA seeds the tokens. They keep the database of token seeds. You can't seed your tokens yourself.

This means you put your trust in RSA, not only that they won't give you defective tokens, but also that they will never have a security breach that compromises your keys.

This is why I use Yubikey. I still have to trust the manufacturers' QA team and technology, but I also get to run my own authentication servers, and SEED MY OWN DAMN KEYS. Such that WE control our security; There is no single central point of failure, like there was/is in RSA's case.

This shit isn't rocket surgery folks: HERE AT RSA WE MAKE YOU PUT ALL YOUR EGGS IN ONE BASKET WITH EVERYONE ELSE'S. WHAT CAN POSSIBLY GO WRONG!?!

I'm not a paid spokesperson for Yubico, but I am outraged that people refuse to use superior products with better security than that moronically designed clusterfsck of a security model that RSA is selling. It's like no one has even tried to look for something better, even after being burned.

I warned my company of this eventuality, and we stopped using RSA. When the RSA breach happened I made popcorn and watched their "security theater" burn. Since the victims have learned nothing I keenly await the sequel.

Really? A $10 Yubikey is more costly?

LastPass (cloud service with browser plugins) supports Yubikey, a low-cost token for two-factor authentication - so someone would have to both install a keylogger on my system and physically steal the Yubikey token to get the LastPass passwords. http://www.yubico.com/

This makes it actually more secure to always use LastPass even if you remember the site password, because the LastPass login is Yubikey protected while the site password isn't (and the way LastPass sends the password to the site doesn't involve the keyboard.)

As with KeePass or 1Password, which are non-cloud services that would be used with Dropbox etc, you must still be very careful with security of the client system - non-keylogger trojans that attack the LastPass plugin or the KeePass/1Password client software could still steal passwords while the password database is open.

Everyone on Windows should be running the free Secunia PSI, which scans all third party and Microsoft apps every week for vulnerability, providing a link to easily update them, and even auto updates some of the most common ones. If everyone did this, drive-by download attacks would be virtually a thing of the past.

Sadly, Mac and Linux don't have this for any apps not handled by the standard MacOS updater or the Linux distro's package repository, but at least with Linux you can limit your use of non-repository apps to those with excellent auto-updating (Firefox, and Chrome as long as your distro doesn't go out of date making Chrome refuse to update!)

Sorry, If it's not open source, compiled in house, and uses data encrypted BEFORE it leaves our network -- It's not a secure service. Also: I put it to you that a closed source program or OS is considered harmful in terms of security and transparency (read trust-ability) -- This goes for LockLizard, Symantec's PGP NetShare, and especially Windows -- The US, UK, Russian, Chinese and other governments have the Windows source code, why is that? Security, and also to look for exploit vectors... Being a security contentious individual, Why don't you insist on having the source of your software too?

Even if you can prove that a certain algorithm is being used to encrypt the data, how can I be sure that the program or OS doesn't contain a key-logger that sends the key and/or data where I don't want it to go (Perhaps via a update request)?

If your "SaaS service" (software as a service service?) has the keys to unlock your data -- Well, Your version of "done right" is very different from mine.

Let's not forget the "trust" we put in RSA tokens, letting RSA keep the root keys, and how hackers cracked the collective single point of failure, then used RSA's keys... If those who got hacked as a result of using RSA's "Security as a Service" had instead used Yubikey, they could have installed their own "seed" keys into their own tokens, thus eliminating the centralized key-store. (Additionally, if RSA wasn't using Windows internally they wouldn't have been vulnerable to the attack vector used against them; Google learned this lesson too.)

A true "Thin Client" or Dumb Client, won't be doing much work with your data, allowing data processing remotely means you have no control over your security. I opt for "Real Clients" and in-house services combined with a "Dumb Cloud" that just stores and fetches encrypted blobs.

In short: If someone else has the keys to your kingdom, how secure are you really? (Lockheed thought they could trust RSA in such a way -- Yep, they both got hacked).
--
Don't get me wrong, apply security as needed; Some systems don't need as much security as others (provided backups are made), but why call a less secure solution "done right"?

Yubikey has secure tokens that you can "seed" yourself, for use with your own authentication servers. The scam is that RSA made some idiots think think there was no way to do this without their auth servers; Thereby fooling fools into using a less secure system with a mandatory recurring payment for RSA (to access the auth servers).

Re-configuration of YubiKeys by customers

For high security environments, customers may select not to share the
AES key information for their YubiKeys outside of their organization.
Customers may also for other reasons want to be in control of all AES
keys programmed into the Yubikey devices. Yubico therefore supports the
use of a personalization tool to reconfigure the YubiKeys with new AES
keys and meta data.

Additionally, I prefer the model that has RFID for physical access.

Relying on an outside source to have our cryptokeys is just adding another point of failure. EVERYONE relying on them is just creating THE BIGGEST point of failure possible... Every time I talked to security minded folks that used RSA tokens, I asked them, "So. How secure are RSAs severs? You do any security audits on them lately?" The blank expressions were priceless.

Have you seen "YubiKey" : http://www.yubico.com/yubikey I use this for pretty much all my authentication now. (where posible) You can either let it auth off their servers or if you don't trust them (I don;'t) you can generate your own auth server for your key or even local auth or flat password. It's pretty cool and you could use it to generate a auth key for the applications you list. But yea.. it's the way to go. No wallet access without me pushing the button on my yubikey.

I've long longed for a USB hardware device containing a small crypto-processor, a public/private keypair, and a button. Given a standardized interface (as standardized as USB block-devices) it would make a perfect key-solution to keep in my physical keychain to identify myself in all kinds of circumstances.

You might be looking for a YubiKey.