Own your own credentials!

Login with Google. Login with Face­book. It’s con­ve­nient. No need to in­vent and re­mem­ber a new user­name, a new pass­word. It’s al­most a sin­gle-sign-on (SSO) to the en­tire in­ter­net.

The ob­vi­ous down­side, how­ever, is that within a sec­ond you could see your­self locked out of many of your ac­counts. Just imag­ine that for some rea­sons your iden­tity provider (Google, Face­book, Apple, …) de­cides that you have vi­o­lated their terms of ser­vice. And locks you out of your ac­count, and as a con­se­quence also of all the ser­vices that you used the ac­count for. Too few peo­ple con­sider this, in my opin­ion. It can hap­pen quite fast (re­cent ex­am­ple in­volv­ing AI).

Of course you can then try to fight this lock and argue your way back into the ac­count. But you need to be very lucky to even get some human’s at­ten­tion on the other side. Un­less you some­how man­age to make a huge buzz on it on (so­cial) media, I bet your chances of get­ting the issue re­solved are pretty thin. Google is even proud that you can’t call them in order to sort this thing out (see Google’s Ac­count Re­cov­ery sup­port page; yes, they are right that you should not use any ex­ter­nal pass­word re­cov­ery ser­vice).

Don’t get me wrong. I love SSO in a com­pany con­text. But there is an admin that I can talk to in case some­thing goes wrong, and if my ac­count is ter­mi­nated, it likely is be­cause my em­ploy­ment is ter­mi­nated. I just don’t like it for my per­sonal data, where some (per­ceived) vi­o­la­tion of some terms of ser­vice of one of the big com­pa­nies might lock me out of all my other un­re­lated ac­counts as well.

I very strongly be­lieve, that any­one mak­ing them­selves a gate­keeper for things out­side their own busi­ness should be, by law, re­quired to not ter­mi­nate your ac­count with­out any re­course. Yes, they can stop doing busi­ness with you. But they should not be al­lowed to stop au­then­ti­cat­ing you.

Passkeys as al­ter­na­tive?

For a while, it seemed that Passkeys would be­come a con­ve­nient and se­cure way of sign­ing in to ser­vices. I, how­ever, only started to con­sider them once Keep­assXC with 2.7.7 started of­fer­ing sup­port for man­ag­ing them in­side the pass­word store, so that I could backup it and would not be de­pend­ing on a hard­ware de­vice that could break or that I could lose.

Un­for­tu­nately, it re­ally seems that the big com­pa­nies are using this tech­nol­ogy yet again to lock you in their ecosys­tem, cre­at­ing ex­actly the same prob­lem for me as I have with the “Login with…” sys­tem. The fol­low­ing ar­ti­cles are a very good sum­mary of what went wrong and also why the cur­rent stan­dard and the in­sis­tence to res­i­dent keys have made this sys­tem ba­si­cally un­us­able for the con­cerns I men­tioned above.

Maybe good sup­port in pass­word stores (like Bit­war­den/Vault­war­den, Keep­assXC, Keep­ass2An­droid) can maybe still make this a vi­able al­ter­na­tive. The cryp­to­graphic ad­van­tages of passkeys over nor­mal user­name/pass­word are great, so I re­ally think it can be an im­prove­ment in the fu­ture.

Stay­ing with user­names and pass­word man­ager (for now)

For now, I’ll still stay with my own setup using my self-man­aged pass­word stores. With all the work and dan­gers this in­curs as well (back­ups, dis­tri­b­u­tion, avail­abil­ity).

To quote from the ar­ti­cle men­tioned above, some­thing that I can ab­solutely en­dorse:

And I’m start­ing to agree – a pass­word man­ager gives a bet­ter ex­pe­ri­ence than passkeys.

That’s right. I’m here say­ing pass­words are a bet­ter ex­pe­ri­ence than passkeys. Do you know how much it pains me to write this sen­tence? (and yes, that means MFA with TOTP is still im­por­tant for pass­words that re­quire mem­o­ri­sa­tion out­side of a pass­word man­ager).

So do your­self a favour. Get some­thing like bit­war­den or if you like self host­ing get vault­war­den. Let it gen­er­ate your pass­words and man­age them. If you re­ally want passkeys, put them in a pass­word man­ager you con­trol. But don’t use a plat­form con­trolled passkey store, and be very care­ful with se­cu­rity keys.

tr.im to be shut down

To em­pha­size my de­murs against URL short­en­ing ser­vices which I have men­tioned be­fore, here comes the prove that my the­sis is cor­rect: the URL short­en­ing ser­vice tr.im is going to be shut down by end of this year. As Robert Scoble put it, this is a “short­com­ing” of the Twit­ter plat­form, where the shut­down most likely will be felt most.

This is the first time I am aware of ac­tual knowl­edge/data-loss which will occur due to the shut­down of such a ser­vice.

Up­date: tr.​im an­nounced that they will stay in busi­ness, due to an over­whelm­ing re­sponse. But still, the final shut­down of such a ser­vice sooner or lat­ter can and will hap­pen. And even worse would be the con­tin­u­a­tion of such a ser­vice where all the URLs would be redi­rected some­where else…

http://​blog.​tr.​im/​post/​160697842/​tr-​im-​resurrected

URL shortening services soon to be under siege?

I have al­ready writ­ten about my opin­ion about the prob­lems of URL short­en­ing back in 2005. Yes­ter­day, Jeff At­wood pointed out other is­sues like com­mer­cial­iza­tion. Today, an­other threat has come true: hack­ers have ma­nip­u­lated the URLs of short­en­ing ser­vice cli.​gs.

Given the huge amount of in­for­ma­tion hid­den be­hind such short­ened URLs, and given the pop­u­lar­ity and num­ber of these links, es­pe­cially nowa­days on Twit­ter, these ser­vices could see them­selves being under per­ma­nent siege of hack­ers/crack­ers. Being able to ma­nip­u­late hun­dred of thou­sands if not even more vastly dis­trib­uted and pop­u­lar URLs to point to a given site could be used for both, gen­er­at­ing (lots of?) ad-rev­enue, or as a new form of DDoS-at­tack.

At the mo­ment there seems to be no way around using these ser­vices (es­pe­cially with ser­vices like Twit­ter), but in the medium/long run a so­lu­tion has to be found if we don’t want to lose lots of valu­able in­for­ma­tion.

Microsoft: Only signed drivers for Windows Vista x64

Ac­cord­ing to this Mi­crosoft page and this Golem-Ar­ti­cle (Ger­man), Mi­crosoft is going to make dri­ver sig­na­tures from Mi­crosoft manda­tory for any dri­ver run­ning in ker­nel space in Win­dows Vista x64. They claim se­cu­rity rea­son for this.​While (faulty) dri­vers def­i­nitely can lead to se­ri­ous (se­cu­rity) prob­lems under Win­dows, they some­times ful­fill cruitial parts, es­pe­cially in win­dows file sys­tem mon­i­tor­ing, for which there are many le­git­i­mate rea­sons. Hav­ing to go through the WHQL for every dri­ver (and every minor patch) seems a lit­tle costly and time con­sum­ing to me…

Well, after all, for me it seems to be three things:

  • Ad­di­tional money through ad­di­tional dri­vers going through WHQL,
  • Anti Open-Source pro­jects,
  • Build­ing up the in­fra­struc­ture for an (al­most un­break­able) Dig­i­tal Rights Man­age­ment sys­tem.

Up­date 2007-01-23: I have to re­vise most points of this, as I now learned some­thing new about it. Vista x64 will ac­cept dig­i­tally signed dri­vers, but they do not nec­es­sar­ily be signed by Mi­crosoft. Read more in my up­dated ar­ti­cle.