Two things:

It works.

It's wonderful.

I love this. I'm logged in to Swarmops (my current project) before my phone has even confirmed it has transmitted the signed nonce. This is as smooth as Lastpass' autologins, except 2FA since it combines what you have with what you know (your phone's password, in this case).

If anybody wants to copy my C#/Asp.Net code, feel free. The relevant parts are easy to extract from Login and BitId here:
https://github.com/Swarmops/Swarmops/tree/master/Site5/Security

They may still be a little unstable with regards to threading on Mono (which sometimes cuts a request short and strange things like that), but the code works at a prototype level.

Cheers,
Rick

I would agree with this and I'm not certain this is even the case. I'm on a wild goose chase for bugs at this point to find out why my implementation isn't responding.

Cheers,
Rick

Ok, now I know exactly what the HTTP request from Onchain looks like (which works against the BitID demo). No wonder I couldn't get it to work. The phone app doesn't use Json at all, but does a full webform post.

This is what I was asking for in the spec as a sample:


And here I was trying to interpret Json and wonder why the server did absolutely nothing...

Thanks, it does! I found at least one reason my server doesn't pick up the response.


Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.


Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.

Testing again now.

Cheers,
Rick

Thanks, but that's not what I need. I'm trying to write a server-side implementation. I need to know what the client is sending to me, and to be honest, that's not specified. I'm in the blind. I'm trying to use a BitID client and just see whatever it is sending by pushing debug code out to production (accessible) servers. That's not how any development should be done but I'm given no choice right now.

In a spec, I'm expecting, and asking for something like this:

SAMPLE CLIENT LOGIN REQUEST


SAMPLE SERVER RESPONSE


Do you see where I'm coming from? It just says that four specific parameters are submitted as part of an HTTP POST. It doesn't say anywhere how those four parameters are encapsulated and encoded. I need to know that in order to implement this. (In this example, I wrote the spec part as if they were submitted using Json, which I don't think they are, but you get the point.)

Cheers,
Rick

Some feedback - this part was not clear to me:


Specifically, in what standard format are the parameters passed? Using Json? Http headers? Encoded onto the Uri? What? A tangible example of the exact HTTP POST request sent from the client, byte by byte, would have been enormously helpful here. As is now, I'm blind on the server side - I don't know what data to expect and have to guess how the client sends its data?

I intend to implement this as a 2FA sign-on in Swarmops over the next two weeks. I've never seen _anything_ matching its ease of use.

Is there redistributable server-side code somewhere I can use as a template? My platform is ASP.Net and C#. I would rather not reimplement crypto code, but I am happy to change its syntax keywords from another implementation language.

Cheers,
Rick


(Swarmops: https://github.com/Swarmops/Swarmops)

I see the privacy gains of not using an existing bitcoin address for authentication.

Will the private keys of this address also be backed up along with the wallet addresses? If not, then some recovery mechanisms will be necessary app-side. I guess that's necessary anyway.

As long as primary UX is point-and-logged-in (no more steps than enabling camera and pointing it at screen), I'm happy. Once this UX is good enough, what are the prospects of getting into the mainline Android client?

Cheers,
Rick

(I'm assuming here that the Android Wallet fork makes use of the fact that the Android wallet already has an address selection mechanism on the home screen, so it's literally just point-and-you're done for authentication; no need to confirm or select signing address?)

I really really REALLY want to launch this as the preferred authentication method for a project I'm developing. The ease-of-use is positively outstanding, and in particular, the lack of need to install Yet Another App as it just piggybacks on the bitcoin wallet. Do we have any idea (best wild-ass guess) when bitID may be available in the mainline Android client, something even marginally better than "between yesterday and in two forevers"?

Cheers,
Rick

I was surprised to find BitID was not yet supported by the standard Android wallet (the one discussed in this forum) as I started doing some server-side login development today.

Are there plans to include it? This is two-factor authentication simpler than a login/password combination, and displaying a QR code as a login challenge on the login screen would be great security-wise AND usability-wise.

Cheers,
Rick

Chiming in:

This particular protocol is the best to happen to usable security in a very, very long time.

This simple protocol extension offers two-factor authentication at higher usability and security than a one-factor login/password combo.

Assuming most people have some sort of screen lock on their phones, this provides for a two-factor authentication at the ease of pointing your phone at the screen. Bravo! Applause!

I actually wanted to start implementing this protocol server-side today, and was surprised to see that my Android wallet didn't yet have support for it.

I can't wait to offer something as simple and secure as this to users of my systems.

Cheers,
Rick

I strongly disagree. Having the Gox price/volume history is and remains absolutely essential, especially right now to find traces of insider trading or other signals to cross-correlate.

That doesn't mean it has to be front page, but don't delete anything FFS.

I did a write-up here on a cold storage setup that a few people have deemed secure. YMMV.

Good point, conceded. It's the one weak link in the chain that you want to eliminate, and on second thought, this is sound security practice.


Again, conceded. I pictured two one-way sessions, where an operator would have to change directions (pretty much like the USB key communications today), but the ability to communicate optically in the first place enables one single session which starts with the transfer of the unsigned transaction and ends with the broadcast of the signed transaction. For extra sci-fi points, there could be audible notifications in a synthetic voice as to what stage the session is in.


Good thinking! I did a short test here, and a laptop plus a desktop computer is also feasible, as long as you have a webcam on top of the desktop computer monitor. You'll have to hold the laptop in place, but still.


I'm going to be a total pain in the ass and disagree with that assumption. I know from myself that I really hate it when people do this, but hear me out and evaluate the thinking here:

Experience with security practices dictate the assumption that your code is the only piece that hasn't been compromised - that yours is the "last piece of code standing". If the Armory binaries have been corrupted through real-time code modification, then the game is over, but there are many cases where malware could have gotten into the offline computer without the ability to affect Armory.

So if Armory is compromised, the game is over. But I would take the position that the offline computer can be compromised in userspace without Armory getting compromised, and even if malware is running all over userspace, Armory could still be very able to perform its task securely. (Of course, if malware makes it to root or kernelspace, the game is over, but that's because of its ability to subvert the Armory I/O or binaries in that case.)

Also, remote code execution isn't the only vulnerability to watch out for. The offline computer can have had malware planted on it through a number of bad means - everything from USB-level exploits through an adversary physically gaining access to the machine and maybe installing a keylogger, sniffers, etc., maybe even in hardware. It's not just remote execution you want to prevent - you want to prevent any ability for the offline computer to communicate anything but signed transactions to the outside world. Having a keylogger or other sniffer is bad, but it may not mean any damage in practice, if and only if those pieces of malware are unable to report their findings to the outside world.

So I'm equally concerned about the elimination of known potential back channels from possible malware on the offline machine. If an Armory user isn't familiar with sound security practices, it could even be code running in a different, deliberately installed user account that is the adversary.

Again, thank you for a great piece of software, and thank you for considering the idea of optical communications. I appreciate that you're already considering sonic communications as a way to mitigate the original problem.

Cheers,
Rick

Hmm, good point. However, in the general case, a display cycling some 1-8 QR codes must surely be sufficient? I just aimed my phone camera at this QR code on Wikipedia, with some 1800 bytes, and it nailed it without blinking. I can't tell how many percent of transactions would be smaller than 6-7 kilobytes, but I imagine it would be the overwhelming majority.

So while there may be cases where this mode of communication is not available, is that a reason to exclude it from the 95%-98% of typical cases?


Is that really the case? The communication would be one-way, there's no need for ACKs as the receiving computer can read the sending screen until all codes have been read. No need for a two-way protocol. There's an operator there, after all, who is alerted to when the data transfer is complete in some way.


I totally agree that usability is key, and that secure usability is one of the bitcoin ecosystem's big problems right now - I'd even call it a showstopper until that problem is solved. However, Armory is already halfway to the point of solving this specific problem with its configurable user levels of advancedness.


An audio channel is a clear improvement over a USB key, but still hijackable as a side channel in the dire case malware has found its way onto the computers: all operating systems I know of allow for multiplexing several simultaneous applications to/from audio. However, in the same vein, webcam access and screen real estate is exclusive to one application, giving an advantage to the operator knowing that Armory has exclusive control of the communications channel?

Oh, and also, I almost forgot: Thank you for this great piece of software.

Cheers,
Rick

The advantage of synchronous optical communications with sender and receiver in one place, as opposed to asynchronous messaging across time or location, is that you can display a visual stream of QR codes. Therefore, there's really no limit to the amount of data transferrable.

Cheers,
Rick

As seen in the howto I posted a few weeks ago, Armory is now my primary wallet for security reasons, as I've chosen to not trust third-party services any longer *cough* Gox *cough*. I believe my fellow Armorists share the concern of coin security, and have chosen Armory for that primary reason.

Once you have your private keys in a manner that they will never ever touch a computer that has been, is, or will be connected to the internet, you need to examine the communications paths with this offline computer from a defense-in-depth perspective.

The weak link today is in how the unsigned transactions go to the offline computer, get signed there, and are moved back to the online computer. Email or clipboard is obviously out of the question, as that would require connecting the cold storage to a network. So realistically, that means a file is stored on some medium, that medium is physically moved to the offline computer and connected there, the transaction is signed, and the medium is moved back. The only medium that is used this way today is a USB stick.

Here's the vulnerable point. USB sticks contain firmware that can be exploited and malware embedded. That, in turn, can be used as an attack vector against a target system's USB drivers. Assuming we trust Armory, which we kind of have to, we want to be sure that no communication can get piggybacked by covert malware onto Armory's communication between its online and offline counterparts.

As long as we're doing that communication on multi-gigabyte USB sticks, the potential for a covert side channel is enormous.

Therefore, seeing how security has been the foundation and priority in building Armory, I'd like to see the ability for the online and offline computers to communicate signed/unsigned transactions optically using QR codes, instead. Have the online computer display the unsigned transaction on-screen with a QR code, have the offline computer use its webcam to read it, and vice versa for the return comms.

That way, we can be much more certain that no covert side channel is being used to extract information from the offline computer. We still must trust Armory, but this was about eliminating the possibility of piggybacking covertly on the transfer of Armory's data, which can be achieved if Armory communicates optically instead of via files.

Comments?

Cheers,
Rick

It's not an 1EnJoy address. See the screenshot I posted.

Verification for bitcoin withdrawals were needed as far back as May 2011, when I started using Gox.