>> (p.1)
    Author Topic: Build a better bitcoin web service?  (Read 2535 times)

    • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 02, 2011, 11:29:46 PM
    Last edit: August 02, 2011, 11:43:36 PM by Newton
     #1
    I find it ironic that Bitcoin (by itself) elegantly solves so many problems people are currently having with their new online money:

    - How to safely, irreversibly, and quickly move funds around (as opposed to Dwolla clawbacks, multi day bank delays all around)
    - How to avoid the need to trust a 3rd party (mybitcoin, bitomat, etc)
    - How to stay safe even if a 3rd party is hacked (Mt Gox exposing everyone's passwords)

    However, I think it is safe to say that 3rd party web services are going to be required if this economy is going to grow.  My mother, for example, would need a simple, easy to use online payment system.

    My proposal:

    An open source ajax web service which performs key actions in browser, and stores data only in encrypted chunks from browser calls.

    From the client view:

     (a)  Client logs into site with username/password
     (b)  Client is presented with personal addressbook, transaction history, account balance, etc.
     (c)  Client can send to funds directly, and peer to peer (transactions within the same web db) can be instantly satisfied (so merchants can adopt)

    From the server view:

    (i)   Login is sent to server, encrypted (stage 1).  Server receives encrypted password, matches against database.  If successful, data blocks can be retrieved to send to client- but these blocks were stored encrypted.  The server never has the key to decrypt and is blind to what the data contains.
    (ii)   Javascript on client browser uses the password to decode the data blocks (stage 2) in order to present seamlessly to the user.
    (iii)   New data to be stored in the account is encrypted by javascript, and sent to the server via ajax requests.


    Private/Public keys:

    The private key is only available encrypted on the server, and only the javascript client side ever "sees" the decrypted key.  This key is used by the browser to sign any new transaction requests, which are then submitted to the network by the server side (to work around browser security).

    The server does maintain a decrypted copy of the public key.  This is used to also maintain a total bitcoin count for that address (since this is public knowledge anyway, no privacy lost).  If one or more requests exceed the total in the blockchain, that request can be instantly denied until verified by the network.

    Although it is still possible for an evil site operator to steal your coins, it is much less likely.  The combination of in browser operation and open source peer review can provide a lot more confidence to the user, and this should be enough trust for day to day spending balances.

    Between the existing js bitcoin and server side bitcoind projects, I think this is feasible.  Not sure if I would have that many hours though, so hopefully somebody else wants to run with this...

    Thoughts?

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 03:45:11 PM
     #2
    Any comments on this?  Or is there a dev thread this should go in?

    We've had potentially $1M of bitcoin stolen or lost at mybitcoin, and a system like this could solve the problem.

    If someone wants to start this project and open source it, I can put in some coding time, I just don't have the time to own it.

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 03, 2011, 03:49:21 PM
     #3
    Quote from: Newton on August 03, 2011, 03:45:11 PM
    Any comments on this?  Or is there a dev thread this should go in?

    We've had potentially $1M of bitcoin stolen or lost at mybitcoin, and a system like this could solve the problem.

    If someone wants to start this project and open source it, I can put in some coding time, I just don't have the time to own it.

    I've been thinking about something similar but unfortunately there are security gaps that current Javascript alone cannot cover. The solutions I can think of usually requires a two factor authentication or at least a Java applet, which then opens up the trust question about the Java applet itself. Or maybe I'm just not l33t enough to see the solution Cheesy

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 03:58:10 PM
     #4
    Quote from: Xephan on August 03, 2011, 03:49:21 PM
    Quote from: Newton on August 03, 2011, 03:45:11 PM
    Any comments on this?  Or is there a dev thread this should go in?

    We've had potentially $1M of bitcoin stolen or lost at mybitcoin, and a system like this could solve the problem.

    If someone wants to start this project and open source it, I can put in some coding time, I just don't have the time to own it.

    I've been thinking about something similar but unfortunately there are security gaps that current Javascript alone cannot cover. The solutions I can think of usually requires a two factor authentication or at least a Java applet, which then opens up the trust question about the Java applet itself. Or maybe I'm just not l33t enough to see the solution Cheesy



    I'd also considered that Java would be a more robust platform to build from.  Its not quite as pure as javascript where everyone can see the code.  But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 03, 2011, 05:30:38 PM
     #5
    Quote from: Newton on August 03, 2011, 03:58:10 PM

    I'd also considered that Java would be a more robust platform to build from.  Its not quite as pure as javascript where everyone can see the code.  But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.

    The problem with Java is the split between Oracle and Google, on top of that, one of the most popular device people use doesn't do Java, or Flash Wink

    And we do want something that works conveniently for everybody.

    Verifying checksums doesn't help when there are likely to be regular updates to the Java client to patch bugs or improve usability/security.

    Even a tech savvy person can't tell if it's a legit change or not compared to the number of web devs who can read Javascript easily. For this reason, the Javascript should not even be minified.

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 06:21:56 PM
     #6
    Quote from: Xephan on August 03, 2011, 05:30:38 PM
    Quote from: Newton on August 03, 2011, 03:58:10 PM

    I'd also considered that Java would be a more robust platform to build from.  Its not quite as pure as javascript where everyone can see the code.  But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.

    The problem with Java is the split between Oracle and Google, on top of that, one of the most popular device people use doesn't do Java, or Flash Wink

    And we do want something that works conveniently for everybody.

    Verifying checksums doesn't help when there are likely to be regular updates to the Java client to patch bugs or improve usability/security.

    Even a tech savvy person can't tell if it's a legit change or not compared to the number of web devs who can read Javascript easily. For this reason, the Javascript should not even be minified.


    Agreed, javascript is the way to go.  Its easy to read, and its on most devices including the important ones for web access (the phone). Obviously its Turing Complete anyway, so it can be done.  It would actually be possible to host the javascript on a separate server than the database as well.  Downloading compressed js code is more trustworthy from an unrelated party that doesn't have access to the data.  And the js would often be cached as well, so some significant size is acceptable.  Again, this is all transparent to the non-technical users, and merely the fact that a motivated technical user could uncover fraud is a deterrent.

    I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser).  Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 03, 2011, 06:50:20 PM
     #7
    Quote from: Newton on August 03, 2011, 06:21:56 PM
    I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser).  Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.

    Like I mentioned in another post, the human factor is something I haven't found a way around. The hacker can be deterred/slowed enough that damage is minimized, but there's really nothing to stop an owner from inserting code to steal passwords or redirect transactions and such.

    The only safeguard is still: don't store more coins than necessary! Cheesy

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 07:02:04 PM
     #8
    Quote from: Xephan on August 03, 2011, 06:50:20 PM
    Quote from: Newton on August 03, 2011, 06:21:56 PM
    I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser).  Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.

    Like I mentioned in another post, the human factor is something I haven't found a way around. The hacker can be deterred/slowed enough that damage is minimized, but there's really nothing to stop an owner from inserting code to steal passwords or redirect transactions and such.

    The only safeguard is still: don't store more coins than necessary! Cheesy


    Yes, the human factor can't be eliminated but I think it is dramatically reduced if the transaction signing takes place on the client side, in browser code.  If the correct javascript is running, the owner doesn't have access to anything giving him the ability to take the funds.

    What the owner does have access to do, is to serve up the wrong code and steal the funds that way.  But doing so immediately exposes the actor to the potential of getting caught (and before he has even been able to profit from it).

    You still want to research and trust the site owner, but its a shit ton better than the mybitcoin or bitomat fiascos.  You or a 3rd party could also keep backups of the encrypted accounts, in case the site was shut down by the hosting company/govt.

    EDIT:  Or, best case- open source team (A) hosts the code/front end, and site operator (B) hosts the database

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 03, 2011, 07:09:13 PM
     #9
    Quote from: Newton on August 03, 2011, 07:02:04 PM
    Yes, the human factor can't be eliminated but I think it is dramatically reduced if the transaction signing takes place on the client side, in browser code.  If the correct javascript is running, the owner doesn't have access to anything giving him the ability to take the funds.

    What the owner does have access to do, is to serve up the wrong code and steal the funds that way.  But doing so immediately exposes the actor to the potential of getting caught (and before he has even been able to profit from it).

    I've thought of that as well but this exposes two surface for attacks.
    First is the owner can serve up code to steal, not funds, but the key/password necessary and send it back. If I were to do this, I wouldn't send the bad code every time. I'll just set my server to serve up an edited copy of the .js every X transactions. Just a matter of time before I get all the public key and minimize the possibility that anybody checking would hit on the sneaking in. And I definitely won't do that until volume is high enough to justify it, so early scrutiny won't help here.

    The other surface is by shifting the signing to the client side, it opens up vulnerability on the user end. A single server(cluster) may be safer in the hands of a group of competent admins, but trying to ensure thousands of users are trojan/virus free? Kinda hard Cheesy

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 07:17:49 PM
     #10
    Quote from: Xephan on August 03, 2011, 07:09:13 PM
    Quote from: Newton on August 03, 2011, 07:02:04 PM
    Yes, the human factor can't be eliminated but I think it is dramatically reduced if the transaction signing takes place on the client side, in browser code.  If the correct javascript is running, the owner doesn't have access to anything giving him the ability to take the funds.

    What the owner does have access to do, is to serve up the wrong code and steal the funds that way.  But doing so immediately exposes the actor to the potential of getting caught (and before he has even been able to profit from it).

    I've thought of that as well but this exposes two surface for attacks.
    First is the owner can serve up code to steal, not funds, but the key/password necessary and send it back. If I were to do this, I wouldn't send the bad code every time. I'll just set my server to serve up an edited copy of the .js every X transactions. Just a matter of time before I get all the public key and minimize the possibility that anybody checking would hit on the sneaking in. And I definitely won't do that until volume is high enough to justify it, so early scrutiny won't help here.

    The other surface is by shifting the signing to the client side, it opens up vulnerability on the user end. A single server(cluster) may be safer in the hands of a group of competent admins, but trying to ensure thousands of users are trojan/virus free? Kinda hard Cheesy


    (1) I see what you're saying, the owner would be more inclined to take the key.  However it is still very different than having unfettered, and hidden access to the key.  The owner would need to make a public move, even if that move is only every X transactions.  He's taking a risk before reward.  And this might expose him for days before any significant payoff which is much different than simply walking off with the $1M in holdings on the server.

    (2) I don't think the key is any less secure in the client browser.  Suppose you keep the key on the server- a trojan hijacking the user still has access to their password, through this, to their funds on the server.

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 03, 2011, 07:40:24 PM
     #11
    Quote from: Newton on August 03, 2011, 07:17:49 PM
    (1) I see what you're saying, the owner would be more inclined to take the key.  However it is still very different than having unfettered, and hidden access to the key.  The owner would need to make a public move, even if that move is only every X transactions.  He's taking a risk before reward.  And this might expose him for days before any significant payoff which is much different than simply walking off with the $1M in holdings on the server.

    True, but there are ways to optimize this strategy once there are volumes. Again assuming the role of the malicious admin, if the system isn't proof against anything I can think of to game it, isn't secure enough to me, I would analyse my user base and their activities for profiling. heck I could do a survey in the name of "improving the service". From there, I should be able to score users into two groups: noobs and savvy. Naturally I would target the noob users for malicious code injection and to further reduce risk and maximize gains, I would only pick on those who store the most bitcoins.

    Again, this is defeated by limiting the value stored, making it more profitable for the admin to remain honest than to risk stealing Cheesy

    Storing the frontend on a public service may be one way but I can foresee businesses who would want to customize their frontend, offer value added and such to gain customers. After all, they can't be doing this just out of goodwill. Even not for profit, servers, bandwidth & power need to be paid for. So they would probably end up using their own modifications instead of using an external front end, unless the community as a whole wants to fund such a service, which would require somebody to admin it and then we're back to the admin as a weakness issue again.


    Quote
    (2) I don't think the key is any less secure in the client browser.  Suppose you keep the key on the server- a trojan hijacking the user still has access to their password, through this, to their funds on the server.

    That's why I figured 2 factor authentication may be necessary. Trojan can steal the password but server won't act on a transaction that doesn't get fully authenticated.

  • ThiagoCMC
    Legendary
    *
    Offline Offline

    Activity: 1204
    Merit: 1000

    ฿itcoin: Currency of Resistance!


    View Profile
    August 03, 2011, 09:38:35 PM
     #12
    I have a lots of ideas to help this...

    As for example, I´m gonna build some kind of online Wallet storage based on Eucalyptus and Ubuntu (open source Cloud Computing).

    1- Each user will have its own private Bitcoin wallet.dat "instance";

    2- The wallet.dat will be stored withing the "Walrus" (Eucalyptus persistent storage);

    3- The Ajax interface can have a "backup wallet button", wich stores your wallet within GmailFS, DropBox, or download it directly to your compúter. Also, after every transaction, the system can automatically backup your wallet in any place you want (pre-configured).

    4- The users will be able to download the wallet.dat to its own computer and open it with Bitcoin software;

    5- The users of this system, will not have access to the "Cloud Frontend", the bitcoin/wallet will be accessed through a Web Ajax Interface only;

    6- The persistent storage of users wallet (Walrus) will be encrypted with the user password, so, the Eucalyptus administrator (ME and my team) will NOT have access to ANY wallet.dat, never.

     In fact, I´m doing this setup right now! But only for my tests and without a Web Ajax Interface...

     This will be easy to use for anybody.

    Cheers!
    Thiago

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 03, 2011, 10:02:43 PM
     #13
    Quote from: ThiagoCMC on August 03, 2011, 09:38:35 PM
    I have a lots of ideas to help this...

    As for example, I´m gonna build some kind of online Wallet storage based on Eucalyptus and Ubuntu (open source Cloud Computing).

    1- Each user will have its own private Bitcoin wallet.dat "instance";

    2- The wallet.dat will be stored withing the "Walrus" (Eucalyptus persistent storage);

    3- The Ajax interface can have a "backup wallet button", wich stores your wallet within GmailFS, DropBox, or download it directly to your compúter. Also, after every transaction, the system can automatically backup your wallet in any place you want (pre-configured).

    4- The users will be able to download the wallet.dat to its own computer and open it with Bitcoin software;

    5- The users of this system, will not have access to the "Cloud Frontend", the bitcoin/wallet will be accessed through a Web Ajax Interface only;

    6- The persistent storage of users wallet (Walrus) will be encrypted with the user password, so, the Eucalyptus administrator (ME and my team) will NOT have access to ANY wallet.dat, never.

     In fact, I´m doing this setup right now! But only for my tests and without a Web Ajax Interface...

     This will be easy to use for anybody.

    Cheers!
    Thiago

    This is all excellent!

    (3) Is a great idea.  Whatever happens to the site (crash, raid, hack, etc) some other system could potentially recover the users bitcoin access.

    What about open sourcing the Ajax front end and hosting the code on gitub or another 3rd party?  Your service could still be the main provider- and collect transaction or storage fees.  But if you brand the solution, and you are first to market, then you should be the dominate player even if someone else uses the code (ie open source shouldn't really hurt your market share, and should increase the total market size).

    But the key thing is that open source helps the end user trust you, which is what the bitcoin community really needs right now.

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 04, 2011, 03:43:35 AM
     #14
    Quote from: ThiagoCMC on August 03, 2011, 09:38:35 PM
    I have a lots of ideas to help this...

    As for example, I´m gonna build some kind of online Wallet storage based on Eucalyptus and Ubuntu (open source Cloud Computing).

    1- Each user will have its own private Bitcoin wallet.dat "instance";

    2- The wallet.dat will be stored withing the "Walrus" (Eucalyptus persistent storage);

    3- The Ajax interface can have a "backup wallet button", wich stores your wallet within GmailFS, DropBox, or download it directly to your compúter. Also, after every transaction, the system can automatically backup your wallet in any place you want (pre-configured).

    4- The users will be able to download the wallet.dat to its own computer and open it with Bitcoin software;

    5- The users of this system, will not have access to the "Cloud Frontend", the bitcoin/wallet will be accessed through a Web Ajax Interface only;

    6- The persistent storage of users wallet (Walrus) will be encrypted with the user password, so, the Eucalyptus administrator (ME and my team) will NOT have access to ANY wallet.dat, never.

    Playing the role of the malignant admin again Smiley

    3. Sounds like the perfect way for a rogue admin to backup a wrong/empty wallet over-writing the user's backup. Or it might not even need to be malicious, a bug could cause the backup wallet to be wiped. Furthermore, sending it to yet another external system seems to be increasing the vectors by which the wallet could be stolen/attacked.

    6. Doesn't stop a rogue admin from capturing the user's passwords in the first place to use for decryption Cheesy

  • ThiagoCMC
    Legendary
    *
    Offline Offline

    Activity: 1204
    Merit: 1000

    ฿itcoin: Currency of Resistance!


    View Profile
    August 04, 2011, 12:19:40 PM
     #15
    Quote from: Xephan on August 04, 2011, 03:43:35 AM
    Quote from: ThiagoCMC on August 03, 2011, 09:38:35 PM
    I have a lots of ideas to help this...

    As for example, I´m gonna build some kind of online Wallet storage based on Eucalyptus and Ubuntu (open source Cloud Computing).

    1- Each user will have its own private Bitcoin wallet.dat "instance";

    2- The wallet.dat will be stored withing the "Walrus" (Eucalyptus persistent storage);

    3- The Ajax interface can have a "backup wallet button", wich stores your wallet within GmailFS, DropBox, or download it directly to your compúter. Also, after every transaction, the system can automatically backup your wallet in any place you want (pre-configured).

    4- The users will be able to download the wallet.dat to its own computer and open it with Bitcoin software;

    5- The users of this system, will not have access to the "Cloud Frontend", the bitcoin/wallet will be accessed through a Web Ajax Interface only;

    6- The persistent storage of users wallet (Walrus) will be encrypted with the user password, so, the Eucalyptus administrator (ME and my team) will NOT have access to ANY wallet.dat, never.

    Playing the role of the malignant admin again Smiley

    3. Sounds like the perfect way for a rogue admin to backup a wrong/empty wallet over-writing the user's backup. Or it might not even need to be malicious, a bug could cause the backup wallet to be wiped. Furthermore, sending it to yet another external system seems to be increasing the vectors by which the wallet could be stolen/attacked.

    6. Doesn't stop a rogue admin from capturing the user's passwords in the first place to use for decryption Cheesy


    3. I have a rule in my IT life: never overwrite anything. This can be so simple as:

    Code:
    #!bin/sh
    BKPTIME=`date +%m:%M:%S-%d-%h-%y`
    tar czf ~/wallet-$BKPTIME.tar ~/.bitcoin/wallet.dat
    cp ~/wallet-$BKPTIME.tar ~/Dropbox/

    6. Right and wrong at same time... All passwords are encrypted and saved intoetc/shadow only (or even a LDAP backend), so, how long will take to decrypt a strong password?! +100 years?!

    6.1. Don't you trust in your system, when you type your password to login into a SSH session?! This can have the same level of security than SSH has.

    Also, it is perfectly possible to encrypt your Dropbox/GmailFS/Ubuntu One/Whater cloud folder too...

    What do you think Xephan?!

    I know that deep inside, trust between two parts must exist but, the provider can have a high level of security and strong backup procedures that a single user never dream about. So, where you prefer to host your wallet.dat?! Within a strong cloud that you can trust for sure or within your freak Windows?!

    Sorry, I don't know if you are using Windows...

    I can garantee that a system created by me, using well know open source tools and pretty well documented, is far, far away more secure than any Windows out there.

    BTW, there is no secure Windows. So, every single person wich hosts their Bitcoins in Windows, have the same level, or worst, of security than MyBitcoin... Windows is a joke... Like the todays online wallet providers.

    Best,
    Thiago

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 04, 2011, 12:38:33 PM
     #16
    Quote from: ThiagoCMC on August 04, 2011, 12:19:40 PM
    3. I have a rule in my IT life: never overwrite anything. This can be so simple as:

    Code:
    #!bin/sh
    BKPTIME=`date +%m:%M:%S-%d-%h-%y`
    tar czf ~/wallet-$BKPTIME.tar ~/.bitcoin/wallet.dat
    cp ~/wallet-$BKPTIME.tar ~/Dropbox/

    You see, one of the consistent problem with the tech-heads in bitcoin is this: You assume every user is going to be a techie or can be expected to learn to do things The Right Way. Fortunately for me, real life has beaten that assumption out of me and paranoia has always proven to be invaluable when things go fubar.

    We both know how to write a bash script and can recognize the common flags for numerous commands to know when somebody's trying to pull a fast one on us. Not the average bitcoin user we want to reach with a "user-friendly" front end.

    The average joe will almost inevitably save the same file to the same location. For many of them, be it on Windows or a Mac, it's going to be the default desktop/Documents folder or equivalent.

    You can be almost 100% sure they are going to over-write the same file.



    Quote
    6. Right and wrong at same time... All passwords are encrypted and saved intoetc/shadow only (or even a LDAP backend), so, how long will take to decrypt a strong password?! +100 years?!

    6.1. Don't you trust in your system, when you type your password to login into a SSH session?! This can have the same level of security than SSH has.

    Only if it's my server I'm SSHing into Wink

    Otherwise, I'm going to assume the other admin has a modified sshd and some logging service that records every single command I send in. Cheesy

    Quote
    Also, it is perfectly possible to encrypt your Dropbox/GmailFS/Ubuntu One/Whater cloud folder too...

    What do you think Xephan?!

    Sorry but I don't trust any "cloud" folder. Especially not when their TOS specifically disavow any responsibility if things got lost/deleted.

    Quote
    I know that deep inside, trust between two parts must exist but, the provider can have a high level of security and strong backup procedures that a single user never dream about. So, where you prefer to host your wallet.dat?! Within a strong cloud that you can trust for sure or within your freak Windows?!

    Sorry, I don't know if you are using Windows...

    I like Linux, I've been testing out and trying out Linux since Slackware and dial up days. Know what turns off the average user? It's when somebody does the I-use-Linux-so-I-am-more-elite-than-you-fools thing on them and go on a rant about their OS. Sad to say, I used to do that too.

    But the average person doesn't care about your OS religion. They want a tool that does what they expect and just works. If there is a problem, the first thing they are going to blame is your program, not the OS, not themselves.

    For the record, I use a mix of Windows, Linux (including Android) and even Apple computers/devices. Whatever works best for the purpose and situation.


    Quote
    I can garantee that a system created by me, using well know open source tools and pretty well documented, is far, far away more secure than any Windows out there.

    BTW, there is no secure Windows. So, every single person wich hosts their Bitcoins in Windows, have the same level, or worst, of security than MyBitcoin... Windows is a joke... Like the todays online wallet providers.

    So you claim, but where's the proof that YOUR system is more secure than any Windows?

    The weakest link in any system is always the user and in some cases, an over-cocky dev Wink

  • Newton (OP)
    Newbie
    *
    Offline Offline

    Activity: 56
    Merit: 0


    View Profile
    August 04, 2011, 03:59:20 PM
     #17
    Quote from: Xephan on August 04, 2011, 03:43:35 AM
    Playing the role of the malignant admin again Smiley

    3. Sounds like the perfect way for a rogue admin to backup a wrong/empty wallet over-writing the user's backup. Or it might not even need to be malicious, a bug could cause the backup wallet to be wiped. Furthermore, sending it to yet another external system seems to be increasing the vectors by which the wallet could be stolen/attacked.

    Two things:
        (a) lost data: I think an automatic backup/export button is safer, rather than less safe.  Sure horrible code might overwrite data, but at least you can have it backed up everywhere.  Also, just to be clear each bitcoin address only needs to be backed up once, even if used for many transactions.

        (b) backup getting hacked:  Bitcoin already exposes all of its encrypted data publicly, in the block chain.  As long as encryption is sufficient, you're just as safe backing up this server elsewhere.  Further, knowing this is incentive to provide strong safe encryption instead of a misguided reliance on the server never getting hacked.  Security through open approach instead of security through obscurity is always better.

    Quote from: Xephan on August 04, 2011, 03:43:35 AM
    6. Doesn't stop a rogue admin from capturing the user's passwords in the first place to use for decryption Cheesy

    Yes, this is the risk.  However as long as the right Ajax code is used, the rogue admin never has access to the user's passwords.  Ideally, this Ajax code could be hosted by a 3rd party open source repository, unrelated to the data admin.

    This is the way I would envision it:
    User browses to "SuperAwesomeBitcoinWallet.com", which is registered and maintained by trusted community members.

    - SSL Certificate on server A confirms identity and secures the transaction.
    - JS code is loaded from server B, an open source repository
    - User logs in, and the ajax loads their bank provider of choice server C
    - Server C loads custom graphics, branding, super awesome user interface, etc, but the Ajax is still from server B

    Server C runs the "business" of branding, customer experience, database storage, etc.  But server C never has access to the user password or unencrypted data.

  • ThiagoCMC
    Legendary
    *
    Offline Offline

    Activity: 1204
    Merit: 1000

    ฿itcoin: Currency of Resistance!


    View Profile
    August 04, 2011, 04:11:19 PM
     #18
    Quote from: Xephan on August 04, 2011, 12:38:33 PM
    Quote from: ThiagoCMC on August 04, 2011, 12:19:40 PM
    3. I have a rule in my IT life: never overwrite anything. This can be so simple as:

    Code:
    #!bin/sh
    BKPTIME=`date +%m:%M:%S-%d-%h-%y`
    tar czf ~/wallet-$BKPTIME.tar ~/.bitcoin/wallet.dat
    cp ~/wallet-$BKPTIME.tar ~/Dropbox/

    You see, one of the consistent problem with the tech-heads in bitcoin is this: You assume every user is going to be a techie or can be expected to learn to do things The Right Way. Fortunately for me, real life has beaten that assumption out of me and paranoia has always proven to be invaluable when things go fubar.

    We both know how to write a bash script and can recognize the common flags for numerous commands to know when somebody's trying to pull a fast one on us. Not the average bitcoin user we want to reach with a "user-friendly" front end.

    The average joe will almost inevitably save the same file to the same location. For many of them, be it on Windows or a Mac, it's going to be the default desktop/Documents folder or equivalent.

    You can be almost 100% sure they are going to over-write the same file.

    Mmmm... I not express myself in the right way... English isn´t my native language...  sorry...  \o/
    This kind of scripting is just an example... I´ll never tell to a user of an Ajax Web Interface to do that... This will be done automatically...

    Quote from: Xephan on August 04, 2011, 12:38:33 PM
    Quote
    6. Right and wrong at same time... All passwords are encrypted and saved intoetc/shadow only (or even a LDAP backend), so, how long will take to decrypt a strong password?! +100 years?!

    6.1. Don't you trust in your system, when you type your password to login into a SSH session?! This can have the same level of security than SSH has.

    Only if it's my server I'm SSHing into Wink

    Otherwise, I'm going to assume the other admin has a modified sshd and some logging service that records every single command I send in. Cheesy


    Agree! But, in my proposal, you will be the owner of your server (virtual in this case), including the Bitcoin binary and wallet.

    What I can do is just provide a pre-configured version for regular people, but you can upload your entire Linux image to that cloud, including the Bitcoin binary...

    I see people saying that a Bitcoin/wallet within a Virtual Machine is not safe but, that is true for crap systems like vmware esx or virtualbox, etc...

    But that is not true for Xen.

    Xen can provide a "security through isolation", so, I, the owner of the phisical server, am unable to access your portion of RAM memory.

    BTW, everybody can check the binaries of a system provided by me, to see if it is original or cracked.

    So, I'll never going to provide a cracked binary (or compiled from a patched source) because my name is what is at stake. And my name, my reputation, is one of the most important things in my life...

    Quote from: Xephan on August 04, 2011, 12:38:33 PM
    Quote
    Also, it is perfectly possible to encrypt your Dropbox/GmailFS/Ubuntu One/Whater cloud folder too...

    What do you think Xephan?!

    Sorry but I don't trust any "cloud" folder. Especially not when their TOS specifically disavow any responsibility if things got lost/deleted.

    I already think on this, first, the cloud folder will host a encrypted wallet, second, the backup will be sent to multiple clouds at the same time, so, you think that your file will be lost/deleted from Dropbox, GmailFS, Ubuntu One and from your PC at the same time?!?!

    Oh! BTW, in my proposal, you will be able to access your wallet.dat through SSHFS!!!   Wink

    Quote from: Xephan on August 04, 2011, 12:38:33 PM
    Quote
    I know that deep inside, trust between two parts must exist but, the provider can have a high level of security and strong backup procedures that a single user never dream about. So, where you prefer to host your wallet.dat?! Within a strong cloud that you can trust for sure or within your freak Windows?!

    Sorry, I don't know if you are using Windows...

    I like Linux, I've been testing out and trying out Linux since Slackware and dial up days. Know what turns off the average user? It's when somebody does the I-use-Linux-so-I-am-more-elite-than-you-fools thing on them and go on a rant about their OS. Sad to say, I used to do that too.

    But the average person doesn't care about your OS religion. They want a tool that does what they expect and just works. If there is a problem, the first thing they are going to blame is your program, not the OS, not themselves.

    For the record, I use a mix of Windows, Linux (including Android) and even Apple computers/devices. Whatever works best for the purpose and situation.


    Quote
    I can garantee that a system created by me, using well know open source tools and pretty well documented, is far, far away more secure than any Windows out there.

    BTW, there is no secure Windows. So, every single person wich hosts their Bitcoins in Windows, have the same level, or worst, of security than MyBitcoin... Windows is a joke... Like the todays online wallet providers.

    So you claim, but where's the proof that YOUR system is more secure than any Windows?
    The weakest link in any system is always the user and in some cases, an over-cocky dev Wink

    You´re right... The non-technical user is the most weakest part of any IT solution, that´s why I propose a solution like this... A solid backend environment, powered by Xen, Linux and Eucalyptus (that is a huge part of the proof), with a easy to use Ajax Web Interface for "normal" people, with automatic backups, etc... People will just need to "link" their google account with the Web Application to start the backup procedures automatically, for example...

    My point is: It is perfectly possible to provide a trusted, secure and easy to use Bitcoin online wallet. Within the law!

    I am the kind of people that trust in everybody for the first time, until somebody proves the contrary.

    I feel that the feeling of trusting in people are going to hell... But this is not the kind of society I want to live. In fact, I think most people are trustable in first place, not the inverse.

    I know that there is many, many thiefs in this world but, I am not one of them. I am one of this people that can be used to make this world, a better place, starting building a safe place for people´s Bitcoins. Because our money, is sacred and sweaty.

    If I gonna build this service, it will be entirely open source, so, you will be able to read my documentation and build one identically with your own computers.

    Nice talk!   Grin

    Regards,
    Thiago

  • Xephan
    Newbie
    *
    Offline Offline

    Activity: 42
    Merit: 0


    View Profile
    August 04, 2011, 04:33:05 PM
     #19
    Quote from: ThiagoCMC on August 04, 2011, 04:11:19 PM
    Agree! But, in my proposal, you will be the owner of your server (virtual in this case), including the Bitcoin binary and wallet.

    What I can do is just provide a pre-configured version for regular people, but you can upload your entire Linux image to that cloud, including the Bitcoin binary...

    I see people saying that a Bitcoin/wallet within a Virtual Machine is not safe but, that is true for crap systems like vmware esx or virtualbox, etc...

    But that is not true for Xen.

    Xen can provide a "security through isolation", so, I, the owner of the phisical server, am unable to access your portion of RAM memory.

    Having to run a VM just to use a wallet is still a little bit overkill. Not to mention the resources needed to keep all those VM running, even using resource over-commit and memory ballooning. Also the long term future of Xen is questionable, being sandwiched by RHEL's preference for KVM and the incumbent leader VMWare.

    Quote
    BTW, everybody can check the binaries of a system provided by me, to see if it is original or cracked.

    So, I'll never going to provide a cracked binary (or compiled from a patched source) because my name is what is at stake. And my name, my reputation, is one of the most important things in my life...

    Yet it's also one of the easiest thing to throw away under the right situations.


    Quote
    I already think on this, first, the cloud folder will host a encrypted wallet, second, the backup will be sent to multiple clouds at the same time, so, you think that your file will be lost/deleted from Dropbox, GmailFS, Ubuntu One and from your PC at the same time?!?!

    Oh! BTW, in my proposal, you will be able to access your wallet.dat through SSHFS!!!   Wink

    The problem is always a compromise between redundancy and security. Strewing so many copies of the wallet around, even encrypted, could invite security concerns.


    Quote
    You´re right... The non-technical user is the most weakest part of any IT solution, that´s why I propose a solution like this... A solid backend environment, powered by Xen, Linux and Eucalyptus (that is a huge part of the proof), with a easy to use Ajax Web Interface for "normal" people, with automatic backups, etc... People will just need to "link" their google account with the Web Application to start the backup procedures automatically, for example...

    One of the cornerstone of Bitcoin is anonymity. Tying the wallet to a Google account? Com'on man, might as well just put out a public list of which transaction belongs to which passport number Cheesy

    Quote
    My point is: It is perfectly possible to provide a trusted, secure and easy to use Bitcoin online wallet. Within the law!

    I am the kind of people that trust in everybody for the first time, until somebody proves the contrary.

    I feel that the feeling of trusting in people are going to hell... But this is not the kind of society I want to live. In fact, I think most people are trustable in first place, not the inverse.

    I know that there is many, many thiefs in this world but, I am not one of them. I am one of this people that can be used to make this world, a better place, starting building a safe place for people´s Bitcoins. Because our money, is sacred and sweaty.

    We start from very different ends I guess Cheesy
    I'm cynical so I assume nobody can be trusted beyond what I'm willing to risk. So I would design such a system that it has to be as secured against myself and everybody else before I considered it secure. Cheesy

    As for the thieves part, a lot of people didn't start out with the intention to be a thief. There are many examples of well meaning people starting things with good intentions, but along the way, things changed, people changed. So while your intentions may be good, the system MUST be secured against you betraying that trust as well.

    Quote

    If I gonna build this service, it will be entirely open source, so, you will be able to read my documentation and build one identically with your own computers.

    All the best man Smiley

  • ThiagoCMC
    Legendary
    *
    Offline Offline

    Activity: 1204
    Merit: 1000

    ฿itcoin: Currency of Resistance!


    View Profile
    August 04, 2011, 05:50:33 PM
     #20
    > One of the cornerstone of Bitcoin is anonymity. Tying the wallet to a Google account?
    > Com'on man, might as well just put out a public list of which transaction belongs to which passport number

    Intersango Bitcoin Exchange already do that!! It is not a big deal... Not for me at least...

    Also, you can create a google account only for that purpose...   Wink

    Honestly, I don´t care too much about anonymity, only my balance is a secret and it will remain a secret in that system...

    BTW, you raised good points here... I´ll take all of it in consideration...

    Best!!   Grin
    Thiago
    Pages: [1] 2 »  All
      Print  
Page 1
Viewing Page: 1

IRLBTC™ © 2025 IRLBTC.com