Bitshares Login(bytemaster.bitshares.org)
bytemaster.bitshares.org
Bitshares Login
http://bytemaster.bitshares.org/article/2014/12/22/BitShares-Login/
7 comments
Yes. This is tradeoff of privacy vs recoverability. The best security means I am completely responsible for my own private keys (or passwords). But if I lose them, no one can reset my password for me.
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.
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.
I'm not sure I understand the distinction between identity owner and identity backup provider. Possession of an unencrypted private key is ownership, in my understanding. To wit, FB might be under some contractual constraint on using that data, but what if they broke that agreement? Would I be able to prove that it wasn't me using my private key? This opens up a "detection" and "enforcement" can of worms.
I think the assumption is that a backup solution is very very strongly encrypted and decrypted on the client side
Someone posted this on the bitshares forum: https://bitsharestalk.org/index.php?topic=12119.msg165957#ms...
This might be a solution to the problem of the potential to loose your private key.
You can create a brain key and have the private key based off that. It is supported by Bitshares but requires advanced CLI usage.
Yet another stab at trying to solve identity on the internet. The problem this will face, just like every other attempt, is that websites want to own their log in process and associated user records.
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.
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.
Some links for those who wanted to read up on said history:
http://en.wikipedia.org/wiki/Microsoft_account see, especially, the references section: http://en.wikipedia.org/wiki/Microsoft_account#References
http://en.wikipedia.org/wiki/Microsoft_account see, especially, the references section: http://en.wikipedia.org/wiki/Microsoft_account#References
User records can still be created and indexed locally, but the actual authentication requires using a trusted 3rd party that is decentralized and can not readily be compromised.
Unlike Microsoft or many other solutions. Although I agree about adoption this is a step in a new direction.
Unlike Microsoft or many other solutions. Although I agree about adoption this is a step in a new direction.
What if the SaaS code itself was decentralized? Or I could run it on my own gear?
I don't really understand what benefit using the backchain for this. If you're already depending on an external application, why not do something simpler with a direct challenge-response like SQRL: https://www.grc.com/sqrl/sqrl.htm
+1 for SQRL. I don't know what it would take to push it over the hump of adoption, but it is a beautifully simple and secure solution. Don't know why it doesn't get more attention.
Blockchains make a decentralized service do authentication. Anything that is centralized is easier to MITM. SQRL may very well have a better user experience but it doesn't appear to be solving the same problem.
SQRL has a number of issues, that imho, make it a good example of quality crypto being put forward in a fairly naive way. In no particular order:
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.
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.
These are great points, but allow me to add to them:
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.
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.
> 3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions?
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.
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.
I wonder if it would work when logging in using a machine which doesn't have the BitShares client installed on it. In my case, I keep BitShares running on a beefier machine than my desktop, being that it has such a high memory footprint. My main BitShares account is only on that machine, & I wouldn't be able to clone it to run in tandem on another machine, AFAIK. I'll have to read up on this later to see how that would work.
A similar project, NameID[1] has been around for a while. The fact that names on Namecoin expire may make it unsuitable for some applications, though.
1. https://nameid.org/
1. https://nameid.org/
Or OneName: https://onename.io/
I think the issue this, and all other identity systems have and will struggle with, is developer adoption.
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.
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.
Exactly. Which is why I'm hesitant to adopt it right away. Why develop a feature that only a tiny fraction of users?
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.
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.
...now that makes sense! What is Bitshares?
There is a lot of different aspects to bitshares. Too many to cover in a comment. From the concept of DAC's (Distributed Autonomous Companies) that have delegates / employees that are paid by the blockchain either through share dilution and/or transaction fees. Bitshares is the first DAC and can be thought of as a bank / brokerage. PeerTracks/bitsharesmusic is the music DAC that just had a ICO see http://www.peertracks.com
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/
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/
BitShares is a platform for stable value cryptocurrencies.
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-...
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-...
A counter-view to just how awesome Bitshares is (I don't fully agree with the article, and I am not the author): http://prestonbyrne.com/2014/08/17/dont-walk-away-run/
The article makes a lot of false points but is right in one respect. It would be a fragile system without a price feed. The price feed is in place now and it works decently.
What false points do you feel it makes?
It is poorly written emotional FUD spreading. What is a specific strong point made? It seems more reasonable to work from the other end.
lol. So, you didn't actually read the article? Cool.
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.)