Check out my awesome site for generating secure OfflineAddress.com

[canton]

The instructions are created for broader audience than the one you're thinking about.

Mike, the instructions I quoted were under the heading "If you're looking for the ultimate approach." In my opinion, downloading a ZIP from github is ultimately more secure than using a live web page, even if it is hosted by Google.

As for ways of validating the integrity / checksum of a live webpage, I've been very interested in this as well but haven't found a solution myself yet. bitaddress.org inserts the SHA checksum into the URL bar itself, but if the server or pointbiz's FTP credentials were compromised, this could easily be spoofed, so my feeling is that this provides a false sense of security.

The "live webpage validation" systems I've considered mostly fall along two lines:

1) A manual checksum process with instructions like, "copy and paste the source code into such and such website, and make sure the checksum matches such-and-such publish checksum." Bleah.

2) A distributed / buddy "check the checksums" network. Something like a github project that deploys as a service that each of us (you, me, pointbiz, brainwallet.org, etc.) runs on our own servers that checks the live HTML checksums of our buddy sites every hour. Users of bitaddress.org would check bitcoinpaperwallet.com to see if bitaddress.org's live checksum matches the github-published checksum, and visa-versa. This way a hacker would have to compromise several services simultaneously to avoid detection. There's a lot that I like about this, but to be effective it would be a little complicated as the user agents and IP addresses of the "checker" websites would have to be unpredictable. Otherwise the compromised site would just serve up the unadulterated web page to the buddy network checksum requests.

But until there's some effective "validate this live webpage" function that a grandma can use, I have to yell loud and clear that it is NOT safe to trust something as vulnerable as paper wallets generation off a live website. The "go offline" instruction isn't significant because a hacked website will produce predictable random numbers just as well.

All websites can get hacked, and it's such a soft juicy target that we must assume that some of our wallet-related sites (bitaddress.org, bitcoinpaperwallet.com, offlineaddress.com, brainwallet.org) WILL be hacked. And we should plan accordingly. That's my $.02.

PS: I've put up a proposal for comments regarding the idea of a third party site that would help validate live bitcoin web services:
https://bitcointalk.org/index.php?topic=413882.0

[minimalB]

That's not yet possible with offlineaddress.com. Once all the code is packed-up as one downloadable file it's harder to continue developing it. So since I'm still adding code to this project on almost daily basis I'm postponing that feature.

Great news, thanks for info!

[mikewoods]

As for ways of validating the integrity / checksum of a live webpage, I've been very interested in this as well but haven't found a solution myself yet. bitaddress.org inserts the SHA checksum into the URL bar itself, but if the server or pointbiz's FTP credentials were compromised, this could easily be spoofed, so my feeling is that this provides a false sense of security.

The "live webpage validation" systems I've considered mostly fall along two lines:

1) A manual checksum process with instructions like, "copy and paste the source code into such and such website, and make sure the checksum matches such-and-such publish checksum." Bleah.

2) A distributed / buddy "check the checksums" network. Something like a github project that deploys as a service that each of us (you, me, pointbiz, brainwallet.org, etc.) runs on our own servers that checks the live HTML checksums of our buddy sites every hour. Users of bitaddress.org would check bitcoinpaperwallet.com to see if bitaddress.org's live checksum matches the github-published checksum, and visa-versa. This way a hacker would have to compromise several services simultaneously to avoid detection. There's a lot that I like about this, but to be effective it would be a little complicated as the user agents and IP addresses of the "checker" websites would have to be unpredictable. Otherwise the compromised site would just serve up the unadulterated web page to the buddy network checksum requests.

But until there's some effective "validate this live webpage" function that a grandma can use, I have to yell loud and clear that it is NOT safe to trust something as vulnerable as paper wallets generation off a live website. The "go offline" instruction isn't significant because a hacked website will produce predictable random numbers just as well.

All websites can get hacked, and it's such a soft juicy target that we must assume that some of our wallet-related sites (bitaddress.org, bitcoinpaperwallet.com, offlineaddress.com, brainwallet.org) WILL be hacked. And we should plan accordingly. That's my $.02.

PS: I've put up a proposal for comments regarding the idea of a third party site that would help validate live bitcoin web services:
https://bitcointalk.org/index.php?topic=413882.0

Thanks for starting the topic, having third-party service check the checksum sounds like a great idea.

[pointbiz]

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.

[mikewoods]

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.

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. 

[canton]

Homepage reads: "What if we steal you private key? We can't, Just load this site, disconnect from internet, and generate your addresses"

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?

[mikewoods]

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.

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?

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. 

[canton]

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

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.

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.

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().

[Its About Sharing]

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.

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?

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. 

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

[bitpop]

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

[mikewoods]

@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.  

[bitpop]

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

[mikewoods]

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

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

[mikewoods]

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?

[canton]

@canton: I've noticed that your site is still accessible from HTTP.

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?

[pointbiz]

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?

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.

[mikewoods]

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!

I'm glad it's fixed now.

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?

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:

Code:

git clone https://github.com/mikewoods/OfflineAddress.com

After that you'll have the whole site locally ready to run, you don't even need to unzip it.

[Dusty]

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

[cblue]

I like it. Thank you.

[mikewoods]

is it possible to protect the keys with BIP38 encryption?

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.