Bitshares Login
bytemaster.bitshares.org
bytemaster.bitshares.org
This sounds amazing and useful to me, but even if it all works perfectly, I do have one serious concern: if you forget the passphrase to your private key, your online identity is owned by nobody. That is a very scary prospect!
(Also, from a usability/understandability perspective, I think there might be a better, if less secure alternative to the blockchain, something like an encrypted twitter that transacting parties "listen to" for the duration of their transaction.)
(Something I've been thinking about is an ultra-secure private key backup protocol/device to address this concern. So far, the best I can come up with is an (instant) photograph of a screen showing a textual representation of the key.)
Ultimately, though, I think we are heading toward separating the ownership of the identity and the backup of the identity. I am ok with owning and backing up my own identity. But maybe my dad feels more comfortable with some 3rd party having a backup for him. In that case he can use someone else to be a trusted backup for him.
Right now, if I want to login to Facebook, then Facebook both serves as my identity owner and my identity backup (e.g. "forgot your password?"). I might be ok with Facebook being a backup provider, but I don't want them to be my identity owner.
The only people that benefit from single sign on are websites that experience high friction on sign ups. i.e. "oh I need to create an account for this?" and close the browser tab. In which case a Twitter or Facebook button makes a lot of sense.
I highly encourage anyone looking to build something like this as more than a fun side project to read up on the fascinating history of Microsoft Passport.
http://en.wikipedia.org/wiki/Microsoft_account see, especially, the references section: http://en.wikipedia.org/wiki/Microsoft_account#References
Unlike Microsoft or many other solutions. Although I agree about adoption this is a step in a new direction.
1. Keys are generated from the master key in a deterministic fashion. This means in the worst case scenario, where your master is compromised, rolling your keys is an all-or-nothing activity. You could just be in for a fun evening of racing to change all your account creds before a bad guy can use them. The only advantage this deterministic scheme has over a traditional encrypted keyring is that master key backups can be squeezed in to a QR code. The big downside is, if you want two or more accounts on, say, Hacker News you'll need to generate two 'master' keys and maintain a keyring anyway. Ugh.
2. Your super-sensitive master key is stored on all your devices. Sure, it's encrypted... but that means you'll need to enter a secure (realistically a ~8 random alphanumeric character) password, and wait a few seconds for strong key derivation, to use it. On mobile this is just a sucky UX, and will likely encourage users to use weak passwords or app writers to provide weaker encryption options, if only for the derived (site-specific) keys.
3. It doesn't provide server authentication, so you still need to depend on something like TLS + traditional CAs to ensure you're actually receiving your QR code from, and sending your signed response to, the services you expect and not MyEvilSite.com.
4. It doesn't provide integrity between the user agent and the signing device. When using optical scanning there's no way for the app to know that I'm signing facebook.com but my browser window actually says failbook.com. Even if the user is diligent there's no way for the user or the app to know whether the QR code on their screen is actually tied to their session cookie for facebook.com, and not another perfectly valid facebook session cookie created by somebody else. There's a weak proposal from Gibson to include IP binding but the IP isn't user/app visible (and if it were, requiring the user to be aware of such things is just bad UX). And even if IP binding is effective it still leaves you open when the attacker can use your IP (NAT, ARP spoofing etc, XSRF will even bypass TLS). The class of attacks open because of this gap in the auth-chain is one of the most insidious on the web atm.
5. The server side implementation has a lot of moving parts. A typical webapp needs to generate a secure session cookie, optionally bind it to the users IP and generate a QR code, wait for a sig from the signing device (under some timeout as to not allow unused codes to clog up the database), map that sig back to the users session, do IP and signature checking, update the session state and then somehow refresh/redirect the original client (or have them do it manually which is a sucky UX).
Frankly SQRL 'the protocol' just isn't very novel, and Gibson has only scratched at accommodating some of the hard user facing problems. Much of the above can fixed, but not all.
If you like QR code mobile authentication (well actually bar codes), go with Clef. They're still vulnerable to much of the above, only encrypt your 2048 bit RSA master key on your phone using your 4 digit numeric PIN, and it's just vanilla OAuth behind the scenes, but they've at least nailed down usability and settled on a relatively secure compromise.
2. This is similar to what I do with my ssh keys today. I mean yeah the wait time is a bit eh and you are right that people will likely end up degrading their security in order to mitigate it, but what's the alternative? Perhaps better education is in order.
3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions? Also, would you clarify what you mean by xsrf bypassing tls, as I don't understand how that would happen and it certainly sounds quite troubling.
5. This isn't really much more involved than secure user/pass auth, and less complex than oauth for example.
Not really. There's no way for the app to know whether the particular QR code it just scanned came via a browser session protected by TLS, using a particular CA chain, connected from a particular IP, at a particular time, or with a particular session id. Even if all that information were encoded in to the QR dataset by the server, and digitally signed, it still need to be verified and counter-signed by the browser before being displayed for scanning. All you're really doing is QR encoding a certificate chain at that point... but in order to do that your browser needs to be cryptographically paired with the app.
What you have right now is TLS CA-certified confidence going in to the browser and "the user thinks this QR code is cool" level confidence going in to the app. The user is a poor substitute for a certificate chain.
> Also, would you clarify what you mean by xsrf bypassing tls
Sorry. I meant XSS. If you can inject script in to a TLS protected SQRL page it's game over (you just replace the QR code with one from http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_gener...) then the IP enforcement, as currently proposed, will pass assuming everyone on that LAN has the same external IP. IP bonding is just a lousy way to emulate a decent session layer.... which is ultimately what HTTP needs to nail this down once and for all.
As a web developer, I'm not spending time adding this to my site until a sufficiently high number of users are using. As it has no value beyond login itself, users will not adopt it. Because users have no adopted it, there's no reason for me to implement it. Because I have not implemented it, there's no reason of users to adopt it. Because…
…you can see the problem.
It's a neat idea, though.
Even so developer adoption can be encouraged. By doing most of the work for the developer: a rails gem that integrates with Devise; a Symphony component; a WordPress plugin, etc.
http://bytemaster.bitshares.org/guest/2014/12/22/How-BitShar...
This login stuff doesn't seem super interesting, but stable cryptocurrencies do to me. BitAuth[1] is a similar idea for using keypairs for authentication. Neither will take off until there's a huge install base for the wallet software, or browsers have embedded the protocol behind a good UI.
[1] http://blog.bitpay.com/2014/07/01/bitauth-for-decentralized-...
To DPOS (Distributed proof of stake) VS bitcoin which is Proof of Work.
It also has distrubted DNS (in the works), a voting platorm (in the works), User Issued Assets (think companies issuing employee stock on the blockchain), BitAssets (stable coins that track a real world counterpart backed up by 3x collateral such as BITUSD).
Some good links for info
http://bytemaster.bitshares.org/ https://bitsharestalk.org/index.php http://www.bitshares.org http://bitshares.tv/ http://www.bitsharesmusicfoundation.org/