Topic: Check out my awesome site for generating secure OfflineAddress.com (Read 12185 times)

Running this locally from a USB drive doesn't seem to work.  Can anybody verify?  Site loads, but generating the addresses, doesnt happen.

This type of subject is why bitcoin is not mainstream and won't be for a while. I would love to store my coins securely and feel I am not going to wake up with them gone. However, the farther I chase the secure-my-coins issue down the rabbit hole the more I am lost in wonderland.

I understand your concern, but this is how "standards" works on the Internet: someone propose one (BIP38), some others implement it (for example Mycelium, that is great), and it becomes used by many users.

And voilà, we have walked the path from a simple proposition to wide usage, now it becomes a standard

Paper wallet without encryption are very insecure, so I strongly advise against its use.

I've been looking into this recently.

The conclusion I've came up with is not to implement BIP38 because in the long run it will hurt users more then it will help them.

Here's why:
BIP38 is still just a proposal (BIP = Bitcoin Improvement Proposal), and it's been a draft for more than a year now. Until it's not accepted as standard there is no guaranty that this proposal won't changes, and it probably will to some extent after it's fully reviewed. Until that time, if I were to implement this, users would be tied to that (non-standardized-now) implementation even when standard changes later. That's why I won't implement it and I advise not to use BIP38 from any other site because it will just bring problems in the long run.

I can think of scenario in future where we have one piece of encrypted date that can be decrypted to different private key using old non-standardized and new standardized BIP38, and which can be then used to create compressed and uncompressed public key. Resulting with 4 addresses. (Compressed key is madness on its own which doesn't bring any benefit to bitcoin community at all, but that's not the topic here...)

Still it might be good idea to implement some other standardized secure way of encrypting important date (private key in this case). AES probably makes seance (which is also proposed to be used inside BIP38) because it's broadly used, secure and standardized. Although data encrypted using AES will be a bit longer then it would be with BIP38, but not much.

I like it. Thank you.

Hello,
is it possible to protect the keys with BIP38 encryption?

I'm glad it's fixed now.


Not much, as I've explained here, dedicated hacker will always succeed.

For power-users the easiest and obvious way is to open terminal and type:
After that you'll have the whole site locally ready to run, you don't even need to unzip it.

This.

Same question for downloading offline address from github. There should be a way for power users to increase their confidence level in this software.

Hmm. I can't replicate this. If I try to access the site via HTTP the connection is always redirected to HTTPS. If you can provide steps to reproduce accessing via HTTP I'd like to see them, thanks!

Regarding mitigating SSLstrip attacks, I haven't found a good solution yet (not with my hosting provider anyway.) Thanks for the tip.

Regarding offlineaddress, once I've loaded the site over SSL, what do I do to make sure the code hasn't been tampered with by a hacker?

I've added HTTPS to my site.

I've also made extra effort so that my site can't be accessed from HTTP anymore, all requests will be redirected to HTTPS.  

@canton: I've noticed that your site is still accessible from HTTP. What's the point of having HTTPS and letting the users access the site over HTTP?

+ and hope current connection is safe, and hope his pgp key is never compromised, and trust the author 

The only protection is to store his pgp key now and use it forever

@canton
@Patel
@IAS

The difference between my 'laziness' and 'expertise' lies in being very well familiar with MitM attacks...

It seems to me that you guys think HTTPS is some kind of 'excellent security', while I'm well aware it's hard to even call it 'good security'.
HTTPS it there to 'make people feel secure', it won't prevent any experience hacker, and that's why I wasn't rushing to add it to my site.

Let me explain how ridiculous is it to think that having HTTPS and signed code will make users safe:

For example caton's site (I hope he doesn't mind discussing vulnerabilities in his site publicly) is open to SSLstrip attack making HTTPS useless in the first place:
1) Site isn't using HSTS (there are no STS headers served).
2) Even if it was using HSTS first-time user could still be attacked. Unless all users are using 'HTTPS everywhere' and caton's site was on their list (which is not the case).
3) Even if all measures above ware implemented (and all users had HTTPS everywhere installed), this would only protect site from active MitM attack that do not compromise the certificate trust model - there are multiple parties that can issue fake SSL certificates that will be accepted by the client.
4) Only solution is to use the public key fingerprint as the server address (anonymous networks such as Tor and I2P), but their DNS is pretty much nonexistent, so the connection will depending on SSL security to obtain the address/public_key. So, it's still not secure!

5) Also signing won't help because:
GitHub link is served from the site (which can be SSLstrip-ed) - attacker can provide link to his repository that has his version of software signed with his key.
GitHub serves STS, and even if we assume user is on correct GitHub page, and has HTTPS everywhere - still, private key to check signature isn't in GitHub, it's served from private site, which is served over HTTP , even worse, it's linked from HTTP site to other site also served over HTTP (so you can chose where to do MitM, and you don't even have to strip HTTPS).
Now, how could that be even remotely secure?

And what about compromising GitHub account (or email) - git history can be rewritten. What about compromising server?

...


There are too many problems to address and dedicated attacker will always succeed!

That attack on randomness can be done on addresses created in the past(!), while MitM attack has to be done on live connection - which makes randomness problem more important (instead of pretending to serve secure site).

Anyway, I'll add HTTPS this week. Peace.  

Usually the server gets hacked, the probability of spoofing the site is lower than that unless at a public Wi-Fi

With my limited security background (really worked with DB's) I understand the HUGE security risks of not having HTTPS on the server. This means, at any time between now and when "the code stops growing too fast", a site wide hack can occur. And only having an "online" version is, has been said, a validation problem. Again, I'm no security expert but this just jumps out at me.

Is it worth risking the money of others here? What is the benefit? To whom? Honestly, does the user taking a risk benefit them or a potential hacker? Why take the chance?
There are sites that have the security and measures that has been brought up here. The world is looking at BTC now. There are extremely skilled hackers out there where money is involved, not to mention governments, agencies, etc. This thread is in part an advertisement for them to get ideas; A bit worrisome. We are talking about an open exploit I would say. I am giving you a website that can deal in millions of dollars and there is no HTTPS there. There is no offline validation.

It doesn't add up to me, how can a person like yourself that clearly is an expert in the area, be making some huge mistakes here? I see it and I'm no expert; I see the vulnerabilities and they scare me. I was brought to this thread because I'm always looking to see what is new in the offline wallet area and while just doing some basic checks, I noticed you had just opened your account both here and on GitHub as well. No guilt by association there, but when dealing with huge amounts of money, I'd say it is fair to look closer. If I'm off here and time bears this out, then apology in advance.

To continue, Would I use the private key I got from a website while it was online a moment before, with no means of validation and on top of that, there is no HTTPS. I can't imagine sending value there (even with the brilliant features regarding RNG's mentioned before). The RNG side may be better, but if there are some basic vulnerabilities at essentially the safe door it really doesn't matter what is below that level.

BTW, some of your ideas sound great, this isn't all criticism. I'm just trying to share what my perspective is. Just being concerned, nothing personal here.

Its about sharing

Mike, this is the crux of the misunderstanding as I see it. If the HTML is compromised because of a MITM attack or because the hosting space is hacked, then the user-provided input will simply be ignored, or fed into a predictive number generator. Users will not be secure.


There is every reason for saying that you shouldn't use HTML loaded from a live website. Telling users they will be safe if they turn off their Internet connection after loading the HTML is misleading, because it discounts the possibility of the HTML being tampered with -- which is a helluvalot more likely than the operating system RNG being flawed or someone finding a predictive pattern to the output from crypto.getRandomValues().

I appreciate your concerns.

Recommendation for downloading zip from GitHub will be added once code base isn't growing too fast. 

If RNG is compromised users will still be secure because all random date is user-provided.

Instructing users to primary check hashes is not appealing to broad audience (you know how hard it is to check hashes or signatures on Windows machines  ).
Discouraging users from using loaded HTML doesn't make sense to me - there is no purpose in having website saying you shouldn't use it.

1) I'm working on this, HTTPS will be added within a week or so.

2) I provide GitHub commit ID, and hashes will be added soon.

In short: yes, there are few things that should be added (like HTTPS and hash validation), and I'm working on it.
I'm concerned about both web security and RNGs. 

Hi Mike,

I'm increasingly concerned with this security approach you're recommending. Can I persuade you to change your recommendation to downloading a ZIP file from github and validating the hash? And actively *discourage* visitors from trusting HTML loaded from a live website? Yours is the only paper wallet site recommending this approach, and I can't figure out why.

There's no reason for a visitor to believe that they derive much additional security from disconnecting from the Internet after loading the offlineaddress.com code live. As you well understand, if the RNG is compromised in the HTML they receive, it doesn't matter whether or not the visitor is still online when they generate wallets.

Your recommendation seems doubly problematic when:

1) You don't force HTTPS on your server, meaning someone with permissions to the router on any network used to visit your site can inject different code as a "man in the middle". Your site is vulnerable to this attack right now, it's extremely difficult to detect, and it can be fairly easily executed by the sysadmin for any company, internet cafe, educational institution, etc.

2) You don't provide a mechanism for a visitor to validate the integrity of the HTML they're receiving from your website against some signed codebase of your own.

In short, you're advocating blind faith in the security of your web server. The only argument I've heard you make in support of this is that it's unrealistic to expect visitors to download a ZIP file from github and run the HTML locally. I'm really alarmed by this. I like your concern about RNGs, but I'm wary of your lack of concern about website security. You've got a nice site, good software, and strong promotion -- but you're advocating a standard of security that's much more relaxed than anyone else doing this. Why is this?

That's great news! I'm very happy to be able to help!

I like how it works now - users will be motivated to try to get that number to 0. 

I've released a new version of bitaddress.org with improvements to the entropy collection:
https://www.bitaddress.org/bitaddress.org-v2.8.0-SHA1-87dcf19f02ee9fb9dd3a8c787bcf52eef944aa82.html
 - more entropy from browser fingerprinting for PRNG seed
 - user can add entropy through URL hash tag
 - seed mouse movement as 16-bit number
 - whole seed pool initially filled by window.crypto.getRandomValues
 - added textbox as an alternative input source for entropy
 - address will not generate without a minimum amount of human added entropy from mouse or keyboard
 - discard mouse movements less than 40ms apart
 - visualize points of entropy collection from the mouse

@mikewoods, thank you for the ideas about discarding mouse movements less than 40ms apart and about visualizing the mouse collection points to encourage people to move the mouse more randomly.

I made this notice on your thread because naturally these two JavaScript solutions are being compared.

I believe where the scripts differ now:

offlineaddress.com) Is not seeding a PRNG it is bypassing the PRNG and using the mouse points as the byte source for the private keys. It requires 32 bytes from mouse movements for each private key.

bitaddress.org) Uses a PRNG that is seeded with a 256 byte array. That initial seed is used by the PRNG to generate 32 bytes for each address on the page based on the same 256 byte seed pool. To inject entropy into the PRNG's seed pool browser fingerprinting, time, key presses, mouse movements and hardware randomness from the OS are all xor'd together. As well the output of the PRNG is xor'd with the hardware randomness.