Topic: Bitcoin Operations and Security Standard (BOSS) (Read 2359 times)

Yes.  And I think that has been suggested several times in several threads suffering to the bitcoinia scam.  Stephen Gornick probably knows where they all are.

With regards to oauth here is an interesting read.
https://bitcointalksearch.org/topic/m.1058906

On of the interesting things of the MintChip Challenge was that each hosted MintChip was assigned a unique SSL client-authentication certificate and a key, signed by the Canadian Mint and  distributed in the form of password-protected PKCS-12 files (.p12). These credentials then had to be installed on the client device prior to accessing any of the hosted services.  I know there is a raging debate about reliability and security of SSL certs due to the microsoft and other compromises, however I found this an  interesting and potential solution to the bitcoin security problem.

would it be good to make a web site about this (wiki style perhaps?), then bitcoin businesses could have various levels of certifications.

Understandable, and there is no reason the private key itself cannot be stored encrypted with symmetric encryption on the server. The symmetric key can be generated/computed from the password on the client side and used to decrypt the private key after its fetched. This is then used to sign the server challenge. This is convenient, with the risk that encrypted private keys are now on the server.

Another option is to use openid/oauth type schemes where the authentication is not done by the server/business in anyway but relies on well known providers such as myopenid, google, facebook.

A yet third option is to have a browser plugin that fetches your private key off a thumbdrive and makes the entire login process seamless. i.e. when you go to the website, as long as the thumbdrive is in your computer, it will fetch the private key, do the authentication and sign you in automatically. You only see a notification of successful login or failure. It can also sign any transaction request, authenticating your request to the server. I'm sure some of the smart folks here could easily write something like this.

I would add yubikey, but that's tying to a vendor.

If people prefer paying half a percent fee on every trade for the convenience of using simple easy to guess passwords on website-type user-interfaces that is the free market in action. For puny trivial sized trades the convenience is probably worth it. Maybe though for at least some people avoiding that fee and having to put up with a secure method of communication with a server might seem worth it when they deal with significant sums.

-MarkM-

As does #bitcoin-otc.

The general public issue is making the signing easier. I think people could grasp having a key-pair. They may not be able to stop themselves losing it. But they are too lazy to bother with a cumbersome gpg signing process to login on a web site.

On Linux/Ubuntu we have a nice password/key manager (Seahorse) but even it doesn't integrate with Firefox and provide a one-step way to sign a challenge. Is there an add-on? There ought to be, as a first step that could prove usefulness for later integrating it into the browser.

Or is using client certificates a secure and easier way for people to authenticate for login?

---
BRUNO = Bitcoin's Researcher, Umpire and Nasty One.

That's very well thought out.

Ok, I don't want to tie anything to a particular technology, but authentication does not require a password to be transmitted. Only proof of being the owner of the identity. Such systems are called zero knowledge authentication systems. Its not "combine different ideas together/buzz words". But I appreciate your indignation. It means you do really care about bitcoin's success and I welcome your input.

http://en.wikipedia.org/wiki/Zero-knowledge_password_proof


Many authentication systems exist that never see a user's password due to public/private encryption.

Essentially works like this:
User has a private key.
Server sends a challenge.
user signs the challenge with his private key
server reads the signed challenge and verifies using the clients public key.

Once identity is established, the client can perform all operations until the session expires.

Blockchain.info uses zero knowledge authentication, as do wuala, spideroak, clipperz, etc.

Yes, exactly, the user's password never goes server-side because the server only needs the client's public key, not their private key and thus not the password they use on their personal machine to secure their private key.

-MarkM-

Ok before I give up this is even worse.

First any authentication should require encryption but blockchain.info is a bad example for an exchange.  Blockchain.info doesn't have access to user funds thus everything can be done client side.  That isn't possible with traditional client server relationship in a "normal exchange".

If you hash the password at the client side then the server is only given the hashed password.  What happens when the password list is compromised?  Yup no brute force needed the attacker can simply impersonate any user by providing their hash (found in the password list).

Authentication should be encrypted (SSL) but hashing should be on server.  markm was talking about the use of public private key cryptography which is a completely different security model.

You can't simply combine different ideas together (traditional exchange, client side wallet, public/private key cryptography) like a bunch of buzz words and thing you are more secure.

This is great folks. All your contributions help. No one person can think of everything.

I'll attach a list of credits with the names of all contributors to acknowledge your efforts in every version.

Thanks. Fix added.

It seems most of the Bitcoin public is unable to grok that Information Security is not a state but a process. This includes authors of standards, apparently.

Users' passphrases should exist only on the user's end, not at the server end.

For more discussion of security standards for bitcoin check out https://bitcointalksearch.org/topic/proposal-for-security-standards-for-bitcoin-exchanges-95745

-MarkM-

This is insufficient.  MD5 salted can be brute forced trivially easy.  Without per record salt of sufficient strength even modern algorithms are at risk.   Even with sufficient salt fast algorithms like SHA-256 leave passwords as long as 8 char (plus all known leaked, and common passwords) vulnerable to attack.



You likely don't want to include a required list of functions but you could provide a list of functions which meet the requirements.

Single round:
SHA-256/512, RIPEMD-160/192, WHIRLPOOL, & Tiger

Multi round (recommended):
BCRYPT, PBKDF2, SCRYPT

My guess is that when presented with a BOSS business and a competing business, the BOSS business will attract more customers. Competition ensures most companies will do the right thing and WANT to attract confidence in their business.

If I'm wrong and everyone wants to keep the current state of affairs, then Bitcoin may not be able to compete with the fiat world and will remain a hobby among the few thousand users here.


That's most certainly going to happen, but less frequently than without BOSS. And everytime it happens, we can amend BOSS to mitigate the newly identified risk.

This, although commendable, is unworkable. Exchanges will not sign up to a policy over which they have no control and there is no clear control/revision mechanism. Indeed an exchange may implement its own policies which are more technically and practically secure.

If you try to put a series of rules in place, they will serve as an excuse for more thefts/losses. "We did X according to the standard, but still got robbed".

The only standard there needs to be is "Don't steal or lose people's money". And as we all know, even this is optional.


BB.

Admit it.. you couldn't wait to use that acronym for SOMETHING

I like this proposal & thinking behind it. Strict self regulation seems to be the best way forward for bitcoin.

Can we add 'mandatory encrypted data backups in at least 2 offsite locations' to the list of company requirements?

If any of us want bitcoin to succeed, we need to achieve the following:

Establish security and auditing standards that bitcoin companies and comply with. This can be publicly posted and edited and companies can post a statement of compliance such as: Complies with bitcoin security standard V2.1

The goal of this is to ensure bitcoin can self-regulate instead of running to the government and begging to be saved from the bad guys. I'm not anti-government regulations per se, but calling in the government to regulate a brand new industry will most certainly stifle innovation.

While there seems to be circumstantial evidence to suggest ZT may have either been a naughty boy or just plain stupid, we need to proceed judiciously. Note that accusations are easy, and tomorrow anyone here with any business could be accused of wrong doing should something go wrong.

We need to put in place transparency and self-regulation so that rampant speculation will have no place.

The fiat financial world is heavily regulated because they had to learn all their lessons the hard way. We don't need to. We should simply apply the lessons here and make BTC a far better product.

For example:
V0.1 of Bitcoin Operations & Security Standard (BOSS 0.1)

Goals of BOSS:

1. Set a standard expectation regarding security and operating procedures.
2. Eliminate, reduce and mitigate losses due to theft or corporate wrongdoing
3. Eliminate, reduce and mitigate losses due to customer action or fraud.
4. Ensure the most up to date security mechanisms are in place.

Users:
1. Every account has 2-factor authentication. [This prevents fraudulent claims of password theft etc]
2. All passwords are salted and hashed. Use state of the art password protection as available using zero knowledge encryption. The unencrypted password should not travel beyond the user's device. Example: blockchain.info [Mitigates loss due to/claim of lost password db]
3. All users who store more than 1000BTC or $10000 USD need to provide scanned copy of govt id. [Large amounts attract theft. Disclosing your identity may be the only way to protect yourself. Prevents Govt coming after corporations for money laundering.]
4. Maximum daily withdrawals are set based on corporate policy. 1000BTC and $10000 recommended. Larger amounts may be allowed after a phone call and verification. [This prevents large losses in case of password theft]
4.a. Optional: withdrawals should go to the same wallet deposits were made from. Customer can always withdraw full amount to the originating wallet, change the designated outgoing wallet and replace the funds as necessary for financial privacy and security. [For some businesses such as mixing services, this makes no sense]

Companies:
5. All Corporate funds are strictly separated from Customer funds. [This makes embezzlement easy to detect and prevents accidental losses]
6. Most BTC are stored in cold wallets. [Prevents large losses due to root privilege compromise]
7. The cold wallets containing more than 1000BTC keys are split among at least 2 officers of the company, so that no one person can withdraw from a cold wallet. Steps should be taken to ensure that these keys portions are not shared and not lost if one of the officers dies or exits the company.
8. Other cold wallets have a maximum amount of 1000BTC beyond which it should split into two cold wallets. [This puts an upper limit on loss from actions of an unscrupulous officer of a company.]
9. Companies will take user privacy very seriously and will not air issues in a public forum. As appropriate, resolve issues with the customer or contact law enforcement. [This will build confidence in bitcoin businesses and prevent slander/accusations of slander]
10. Where appropriate, companies should insure against losses of user funds from theft, loss of keys, disruption of operations, etc. This does not apply to trading losses caused by user's own actions. [Builds confidence and permits outside entity, i.e. the insurance company to audit security procedures]

Added per suggestions:
11. All operational data including user data, financial transactions, software state and configs should be encrypted and backed up to at least one geographically separate location. 2 copies in two geographically isolated locations recommended. [Everything is gone! is no longer a valid argument]