I'm pleased to announce that GLBSE 2.0 is now available for testing at http://dev.glbse.com

We'll be adding features and bug fixing like crazy over the next week in the build up to the official launch and swapover from the old system.

Give it a try and leave feedback

For almost every website you visit or have an account on, you got a username and password. CodingHorror has touched on the issue with what it thinks may be the solution. He points out the problems just fine, but I'm not sure his solution is any different to LastPass or KeePass.

The current system is complicated and brittle, one mistake on the side the website developer or the user often becomes a disaster for one or both.

I would like to use this opportunity, while this is a hot topic to present GLBSE's (imperfect) solution.

Webkeys the genesis

When I first started developing GLBSE, I fretted about the task of storing users passwords, I made the assumption that at some point we would have a breach and the database would be compromised. If I had gone for the standard username/password method I'd probably have used a bcrypt+salt solution. Making cracking the passwords computationally expensive.

I then began to wonder how could we get away with not using passwords at all, what if we could verify the user without them having to send us some secret information that we need to guard with our lives, and it clicked. What about cryptographic keypairs?

This solved a lot of issues for user authentication/authorisation. It allowed us to identify a user, and verify that it was them without us ever keeping hold of any secret information, such that we could public our user database on the net and have absolutely no problems.

The user would create a pair of RSA keys (you could use ECC keys also if you liked, but not on our system) on the client, keeping the private key and sending the public key to the server. The users id is a sha256 hash of the users public key (making it difficult to compromise the database swaping in your own public key if the server checks each time).

All requests send from the client to the server are signed by the private key, the server then uses the public key to verify the authenticity of the request (has it been changed, is it by the actual owner of that account?). If the signature checks out, then allow the request to continue, otherwise reqject the request.

Our first client application was written in python and meant to be used from the command line did just this. All requests to the server were http POST requests, json strings that were base64 encoded. These requests were then signed by the private key with the signature also being base64 encoded and sent along with the request.

When the server gets the request it used the signature to verify that the data being sent was good. Short of breaking RSA or the private key being stolen there are weaknesses to this system (beyond it's implementation, which is almost always the weakest point). We used OpenSSL as our cryptographic library.

See here to look at the code for our first client.

Webkeys now

After a very short time we came to the conclusion that if GLBSE was going to be even a little bit successful we needed to go beyond our command line client, we needed something easy to use, we needed a webclient.

Something that was wasy to use from the browser that did not require any installation. Our only choice (if we wanted to avoid the standard username/password system) was to write a self contained JavaScript application that could do everything the command line client could.

I hired a very capable JavaScript developer and together we began to knock into shape an application that could do just that.

The source code for our web client is available here

The web client stores the private keys in HTML5's local storage on the client machine/browser as a json encoded string (this can be exported/imported allowing the user to copy their keys across machines and browsers). All requests are signed by the RSA private key before being sent to the server, just like the command line client.

A webkey looks like:

[
    {
        "label": "public_test_account",
        "id": "sha256_of_public_key",
        "publicKey": "....",
        "privateKey": "....."
    },

 {
        "label": "public_test_account2",
        "id": "...",
        "publicKey": "....",
        "privateKey": "....."
    }
]

As you can see you can have plenty of keys in your webkey-chain, giving them all different labels.

See here for a webkey with the included RSA private key.

Current Limitations

There are a few limitations to this:

1. Insecure environment, Javascript in the browser is not secure, being vulnerable to being effected by Javascript running in a different window
2. Keys in HTML5 storage available only to the website they served from, this is a HTML security issue, this is actually a security feature.
3. Keys must be manually copied to different browsers/machines and are lost if HTML5 local storage is cleared.
4. Resource intensive, cryptgraphy in Javascript is not fast, and RSA signature verfication on the server isn't cheap

Overcoming limitations

1. Browser vendors must do more to prevent Javascript from one DOM, accessing another DOM
2. Have the keys stored on a dedicated USD device that does the signing (needs browser support) similar to Ubikey
3. Have a browser plugin (or full browser support) for backing up keys and performing signatures.

Advantages

• Very, very, very secure (if implemented correctly)
• Can use the same key for multiple websites
• iPhone and Android clients can use keys or act as a portable keyring
• Overcomes the username/password problem
• Allows the complete separation of application and interface into a plaform and client that accesses it.

See webkeys in action, go to http://glbse.com and login/create an account.

Note: With the command line client the RSA keypairs are generated using the client itself. Due to resource issues with having Javascript generate keypairs (takes a looooooooong time), and with Javascripts lack of a decent random number generator the webclient has the server generate the keypairs for it (the server doesn't record these).

Also to ensure the webclient is not changed en-route when being downloaded from the server it must be delivered over an encrypted connection (https/ssl/tls).

The whole Certificate Authority (CA) system as it currently stands is a scam. And browser vendors such as Mozilla, Microsoft, and Google are in on the whole thing. Actually the entire scam is only possible with their support (or at the very least complacency).

And what's worse, is that this system not only costs us a fortune annually to keep going but it's now also costing us blood.

Until a few months ago GLBSE.com did not use a CA signed certificate, actually prior to us launching our Javascript web client we didn't use any encryption (we didn't need to, no passwords, we use webkeys). When we did start we used a self signed certificate (not signed by a CA).

What was the result?

Almost immediately we got complaints from our users, caused by the warnings that browsers such as Firefox and Google's Chrome throw up on getting a self signed certificate, that looks something like this:

All browsers do this, unless the certificate is signed by a CA you're going to see something like this. A savy user may just click through this, but a non-technical one is going to have the crap scared out of them and not go on.

Eventually we gave into pressure and went and got a signed cert just to get rid of this warning.

What's going on here?

There are really two issues when we talk about SSL, one is knowing who the site is (this is a certificate for glbse.com and not www.google.com), and the other is encrypting the data sent between your computer and the website.

Any ssl certificate, self or CA signed can provide the needed encryption and signed certificates are not in any way shape or form any better (or worse) than CA signed ones.

The problem is where CA signed certificates come in, their intended purpose being to prove by third party (the CA) that this website is who they say they are. It has been highlighted many times in the past a a systemic weakness of the whole SSL CA system but was mostly ignored as not being a real world threat.

This threat can no longer be ignored as it's becoming ever more common to find CA's and their certificates being compromised.

We had Comodo recently issue bogus certificates for several important websites, the recent DigiNotar breach, and now a hacker is claiming to have breached up to 4 other CA's.

CA's can nolonger prove that the website is who they say they are. For the system to work you must trust all CA's (of the 50+) who have root certificates in your browser.

GoDaddy and Verisign have such a large proportion of the SSL signed cert market that no browser vendor would remove their root certificates from the browsers in the event of a breach (as was the case with Comodo and DigiNotar).

These two companies are too big to fail, and as a result make the entire system worthless.

Where is the blood?

The blood comes from a number of popular websites SSL being breached as a result of CA's certificates being breached which have allowed some governments (that do not have their own CA's) to spy on some of their citizens. In DigiNotars case it was Iranian citizens that were the target, using forged certificates allowed the offendor (most likely the Iranian government) to run a Man in the Middle attack(MITM) and eavesdrop of their citizens private communications. This only happened over a period of a few days but how many Iranians are in a lot of trouble as a result of this we won't know.

There is also the case that the Chinese government can selectively perform a MITM attack on any user inside Chinese territory that isn't using a VPN to access the internet. All browsers include China's China Internet Network Information Center(CNNIC) as a root certificate. This means that your browser (any browser) will accept any certificate that is signed by this CA. Despite Mozilla giving the CNNIC the green light it is a fact that being based in China they are subject to the demands of the Chinese Communist Party/Government.

All traffic leaving China goes through the Great Firewall of China, this would allow the Chinese government to easily and selectively perform MITM attacks without being detected. It's not just possible that this has happened but is probably, with the government having in the past targeted Chinese human rights activists.

The CA system as it currently stands is not just broken, it's dangerously broken, putting lives at risk while costing us a fortune.

Solutions?

The only ones who can provide a solution are the browser vendors (Google, Mozilla and Microsoft). Long term we need an alternative system to trusting(to not fuck up or do nasty stuff) over 50 CA's based all around the world. The best I've  seen so far is having 3rd parties verify whether you are getting the same certificate as they are, and you're browser notifying you of a certificate change.

Short term browser vendors need to stop throwing up massive warnings (something small would suffice) when going to websites with self signed certificates. Cryptography is better than none.

CA's are more of a libability now than a benefit, they don't even do their job properly handing out signed certs with almost no verification.

We've made the source code of our JavaScript web client available (idea's for licence to use appreciated).

We've also made available a new Python client library called GLIBSE, which is configured to work out of the box with our test GLBSE server and makes interacting with GLBSE easy(with much thanks to cuddlefish and Beamer).

We have a test server for everyone to use and play with, check for vulnerabilities and test your code. The dev server is also the next server to run live, so anything that is running on dev (being perfected) is coming soon, very soon to GLBSE live.

Currently there is very little documentation, so you're best looking through the source but it's something were working on.

The test servers api urls are not the same as the live server, it is what we will be moving our live server over to in the near future.

Tech details here: https://gitorious.org/black-market/pages/Home

Finally we have some great news of whats to come.

• Current version of dev will be moved to live by the end of the week.
• Account to account transfers.
• Exchange in a box, where all you need to start an exchange is a bank account.

Also once we've moved dev to live we will begin pushing GLBSE as a secure web-wallet for bitcoin.

We've added a central place for people to find information about companies listed on GLBSE.com, by clicking the "Listed Companies" link on our homepage or  visiting http://companies.herokuapp.com you will be able to find plenty of information on companies there.

As an example you can see the page for Bitcoin Global .

Compaines can link to their:

• homepage
• twitter page
• financial information (if present)
• forum or any forum thread on their company
• blog

They can also list their contact information and have a basic summary of what their company does.

I'm surprised by the amount of interest in my experience, and after reading the comments on this blog (and elsewhere) I think I should provide some more details to clarify things.

Tell the truth

Some commenters were advising to lie to immigration(or lie better). This is BAD advice, yes you may slip through but it raises the stakes if you're caught telling porkies.

The worst thing to happen to me (and anyone else who doesn't lie) was I was refused entry THAT time, and can come back in the future after getting a visa. If you lie, and are caught then:

1) They can arrest, prosecute and imprison you, it is a crime to lie to the CBP agents, although they told me they don't like to do this as they see it as a waste of taxpayers money. But if you insist on not telling the truth, and keep it up throughout questioning, and they don't believe you, you will do time. Then when you're done they'll deport you.

2)  They deport you anyway, their say is final (unless you have a visa, in which case a judges say is final if you dispute), and they make a note to never let you into the country ever again, banned, for life.

So in short don't lie, it's not worth it.

Another theme that was common in a number of comments was why they decided refuse entry. The most common guess is that it was for lack of acceptable funds. This is one of the many possible reasons(and it could have been for a combination of reasons) that they may have had, but we don't know. The words used (not exactly, but more or less these words):

At this time we are refusing to grant you admission into the USA under law XYZ, for reasons that the purpose of your journey is not covered under the Visa Waver Program, but that you may in the future apply for a visa (business visa) to enter the USA.

Extract from that what you will.

No Credit Card no entry

On why I didn't have a credit card (or more cash), $600 is all I could rustle up in the time prior to the trip, as I'd mentioned I was planning to exchange a fair amount on arrival, and had less than a week to prepare.

In China credit cards are not all that popular, with most people not having them. Online (and in store) purchases are done with debit cards that cannot be used in the US (although they work in Thailand and some other SE Asian countries). I did have some credit cards from home but have allowed them to expire as making repayments is too expensive when doing it internationally, especially on a monthly basis. Now having been living in China for some time I'm probably not elligable for a credit card at all.

Which raises an intersting point, what about people who for whatever reason cannot get a credit card (bad credit history, just moved, whatever)? When we make credit card ownership mandatory for taking part in society (paying for various government services, online purchases, entering the country, getting a hotel room etc.) a significant chunk of people are then excluded because they don't or can't qualify for a credit card.

What would have been equally bad would be to have had enough funds in cash to cover my trip, the amount would have needed to be between $3-5k, which would also have raised flags. It seems the "ideal" tactic is to have some cash (a few hunder dollars) and one or or two credit cards. Too much or too little cash raises eyebrows.

Be on guard

When you're giving them you're passport the CBP agents ask you questions, they always ask "purpose of visit, how long are you staying, where will you be traveling, how much do you have". Sometimes they ask more questions than this. They asked me if I was married "yes", then next question was "Why is your wife not coming with you?". That caught me off guard (I was tired from travelling, and had different memories of what it was like to travel to the states from 2000), which is what some of those questions are meant to do. I mumbled something about not getting a visa. A friend of mine who was traveling there for a conference had planned his stay for 8 days. The agent asked him how long was the conference? "3 days", Why are you staying for 8 then?

Don't mention bitcoin

Much was made of the fact that I had mentioned bitcoin, and looking back I certainly think I would "rephrase" how I was going to support myself. I had already been flagged down by the agent for further questioning, they(there were 3 agents around me at that time asking questions) wanted to know why I only had $600 and how I was going to support myself. 

My options were:

1) Lie -"My friend is going to give me some cash when I get through." See above on why this is a bad idea.

2) Stay silent, not answer the question (not much of an option if I want them to let me in).

3) Tell them I would be exchanging bitcoin to pay for my stay.

I chose option 3

Phone and iPad copying

On the issue of when they inspected and copied my phone and iPad, prior to leaving I had wiped both devices, my phone had some person numbers (not much use as they're Chinese, DHS doesn't do much intelligence sharing with them), and a map from the airport to startpad.org's offices. They did not contain my bitcoin wallet or any other information.

I had been in questioning in the office for about 2-3 hours already before they searched me and took my devices. I guess it was a "might as well, while he's here" sort of thing. Was my privacy violated? Yes and no, I'm sure I could have objected, and maybe they would have listened, but they certainly would not have let me into the country. Because of their position of power CBP has no difficulty getting full cooperation from non-US nationals, they want in, and CBP can at any time refuse them entry.I wanted in, so I cooperated.

If you're an American citizen then the situation is different, you can't be refused entry to your own country, but it doesn't mean that they won't detain you or take your computer off you if you refuse to give them what they want, you have rights if you're willing to stand up for them.

To protect your privacy your best option is to wipe your machine and devices of any information (as you will always miss that little important detail otherwise), and restore from the internet once you're in and clear.

Also keep in mind that CBP may also bug your computer, a friend of mine told me of how they had taken his laptop to "inspect" it, returning it 10 minutes later saying that it was a mistake. In that time they had installed a rootkit that monitored keystrokes. On starting up his laptop when getting to his hotel his intrusion detection system was alerting him. This was on an internal flight.

No electronic devices

Apart from the cost, and trouble caused, the thing that really bothered me was how paranoid they were. Making sure that they were not being monitored or recorded or the people being detained were communicating with someone outside. No electronic devices. They know who you are, they have your finger prints, a high res picture of your face, your travel details, passport copies, family tree, everything. But you are not allowed to record your interaction with them, and I'm sure doing so is probably a federal offence.

I was hoping for my first post on this blog to be about something good, sadly thats not going to be the case.

Tuesday monrning July 19th I arrived in Seattle airport, stoked, excited, this was going to be the begining of a great adventure and I couldn't wait to get started (I'd been traveling...in seats only, since Sunday evening).

Except that's where it ended.

On passing though passport control they scanned my finger prints and I was asked the usual questions.

Purpose of visit?, where will you be traveling to?, how long will you be here for? how much money do you have or do you have credit cards?

Travel and visiting, Seattle and San Fransisco, maybe New York, a little less than 2 months, $600.

It was the answer to the last question that got a raised eyebrow and a red card put in my passport, and off I went to the corner for further questioning by the Customs and Border Protection(CBP) agents.

Before continuing I would like to mention that during the entire process, most (not all) of the agents were courtious, asking if I needed the bathroom, a glass of water or something to eat. During the later part of my "stay" they had lightened up to the point that they would chat with me. As people they're ok, one guy was an ex marine who had done a tour of Iraq.

One thing you realise when your in the CBP detainment area is that they are serious about electronic devices, there are plenty of signs everywhere and usually when someone is brought in one of the first things the agents ask is "do you have a phone?", people take them out and the phones taken off them. Sometimes they forget, and the agents take the phone off them when the person starts using them. There is (unsurprisingly) no internet and without your phone you're pretty much cut off.

I was put into a small office when the five to six hours questioning began,did I have a credit card? How come I ony had $600? What the hell is bitcoin?

Although I was cash poor I had more than enough bitcoin to cover all the costs of my trip and stay, I was going to be meeting with bitoption later that morning in Seattle, he had $1500 of cash to exchange. I explained this to the agents and then the topic of the questioning turned to how bitcoin worked.

After about an hour of that, they took my iPad and brought back my phone, asked if either of them were locked, and then made copies of what was stored on both. They searched me, and my bags, I was questioned and cross examined on who I would be visiting, what I would be doing, and how I exchange bitcoin for dollars or services , how I got the bitcoins... for hours.

Finally I was informed that I would not be entering the United States on that day, but that I would be able to apply for a visa in the future, and if given should be able to return. I was also informed that my return ticket was going to be used to send me back to China. The agent then put on some rubber gloves, at this I started to get a little panicky but the agent assured me it was for taking finger prints.

They then took some headshots and got some high-def scans of my finger prints.

I then spent the next 12-14 hours on an uncomfortable airport chair (the ones designed to prevent you from lying down) in the detention area, watching the CBP agents doing pretty much the same thing to other passengers (the majority of whom were allowed in).

About 2 hours before my flight I was allowed to make a phone call.

An agent came and escorted me to the plane, handed the steward my passports, and showed me my seat. On arriving in Beijing my passports were given to a Chinese imigration agent, who then escorted me to another detention room where I was questioned for a further 3 hours on why I had been returned from the U.S.

It was 1AM Wednesday 20th July when I was "released", 11AM that day I caught an internal flight to the town I'm living in.

Some details I'd like to include, I had arrived using the Visa Waiver Program, which is an agreement that the U.S. has with a number of countries to allow travel for business or pleasure purposes without a need for a visa for up to three months. Being Irish and British normally I would be able to take advantage of this and I did, but doing so give s the CBP officers the final say on whether you're allowed to enter the country or not (whereas if you've gotten a visa, it can be brough before a judge).

Also the last time I had come to the states was in September 2000, from what I remember is passport control checking your passport, asking the purpose of the visit, and thats it. Things have certainly changed since then, and it coud probably be put down to my nievety that I was not prepared for this.

Also I'd planned to meet Peter at startpad.org's offices on arriving, and the only phone number I had was for startpad.org, but for whatever reason the CBP guys were not able to get an answer. So that didn't help.

Advice:

Bring enough cash or credit cards to cover the cost of your trip upfront, having bitcoin that you could then exchange while in the U.S. is not something they will accept.

Avoid any mention of bitcoin, they don't like it at all.

Have a "friend" in the city you're landing in, have their phone number and have a story worked out with each other before you leave.

If you're not Canadian then go to a U.S. embassy and get a visa (even if you qualify for the visa waiver program), if you get one it makes it a lot more difficult for them to refuse you.

Finally don't lie, they will find out, and they are likely to ban you for life from entering the U.S. ever again.

Nefario.