1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 27, 2012, 06:19:41 PM Last edit: July 27, 2012, 10:53:26 PM by 1QaZxSw2 |
|
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]
|
|
|
|
ninjarobot
|
|
July 27, 2012, 06:33:55 PM |
|
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?
|
|
|
|
goodlord666
Sr. Member
Offline
Activity: 434
Merit: 250
100%
|
|
July 27, 2012, 06:38:22 PM |
|
Admit it.. you couldn't wait to use that acronym for SOMETHING
|
|
|
|
BitBuster
Member
Offline
Activity: 101
Merit: 10
|
|
July 27, 2012, 08:17:41 PM |
|
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.
|
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 27, 2012, 09:29:35 PM |
|
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.
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. "We did X and got robbed"
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.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
July 27, 2012, 09:40:56 PM |
|
2. All passwords are salted and hashed. [Mitigates loss due to/claim of lost password db] 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. 2. All passwords will be salted and hashed. Salt is be randomly assigned on a per password basis and will be at least 64 bits (128 recommended). The hashing algorithm should have at least 128 bit keyspace (256 bit recommended) and have no known cryptographic flaws (that excludes MD5, SHA-1, GOST, RIPEMD-64, etc). The use of multi-round key hardening system (such as BCRYPT or PBKDF2) is strongly recommended. The list of secure algorithms, salt, and keyspace requirements will be updated based on new cryptographic flaws. 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
|
|
|
|
markm
Legendary
Offline
Activity: 3010
Merit: 1121
|
|
July 27, 2012, 10:06:41 PM |
|
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://bitcointalk.org/index.php?topic=95745.0-MarkM-
|
|
|
|
Vladimir
|
|
July 27, 2012, 10:09:05 PM |
|
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.
|
-
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 27, 2012, 10:53:44 PM |
|
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.
Thanks. Fix added.
|
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 27, 2012, 10:56:06 PM |
|
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.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
July 28, 2012, 12:56:15 AM |
|
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] 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.
|
|
|
|
markm
Legendary
Offline
Activity: 3010
Merit: 1121
|
|
July 28, 2012, 01:55:28 AM |
|
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-
|
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 28, 2012, 06:02:45 AM |
|
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_proofMany 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.
|
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 28, 2012, 06:06:03 AM |
|
That's very well thought out.
|
|
|
|
BkkCoins
|
|
July 28, 2012, 10:25:14 AM |
|
Blockchain.info uses zero knowledge authentication, as do wuala, spideroak, clipperz, etc.
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.
|
|
|
|
markm
Legendary
Offline
Activity: 3010
Merit: 1121
|
|
July 28, 2012, 01:00:27 PM |
|
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-
|
|
|
|
1QaZxSw2 (OP)
Member
Offline
Activity: 89
Merit: 13
|
|
July 28, 2012, 04:23:24 PM |
|
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-
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.
|
|
|
|
Herodes
|
|
July 28, 2012, 06:01:18 PM |
|
would it be good to make a web site about this (wiki style perhaps?), then bitcoin businesses could have various levels of certifications.
|
|
|
|
BCB
CTG
VIP
Legendary
Offline
Activity: 1078
Merit: 1002
BCJ
|
|
July 28, 2012, 06:16:27 PM |
|
would it be good to make a web site about this (wiki style perhaps?), then bitcoin businesses could have various levels of certifications. 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://bitcointalk.org/index.php?topic=96089.msg1058906#msg1058906On 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.
|
|
|
|
|