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

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 

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

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. 

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. 

True, we just have to be patient now.

Unless PayPal figures out that he'll die if Bitcoin grows, and decides to put in their 'Terms' that you're not allowed to except PayPal payments if you're accepting Bitcoins.

It's less popular if you look 30 days back: 
https://www.google.com/trends/explore#q=bitcoin&date=today%201-m&cmpt=q

However, if you look at last 90 days, it's better then November:   
https://www.google.com/trends/explore#q=bitcoin&date=today%203-m&cmpt=q

"Classified Ads format" -  sounds like a lot of verifications/limitations/additional_problems

People don't know what they talk about.
It's like asking my mom what she thinks about SHA256.

China has a lot of people, but their purchasing power is smaller then most people think, they aren't that important.

Just start writing any passwords hints down.
I had similar problem and I ended up building program that generated all possible passwords based on hints I had - few hundreds of those - which ended up containing the correct one.

Yes, thank you cAPSLOCK.

Bitcoin has to be transparent, even in hacking situations that hurts majority of users. Even whole countries (and their currencies) fall and rise, we just have to live with it.

Replaced, probably not.
Think of countries in EU that excepted Euro as official currency, they still use their old currencies as well.

ATM leaves no traces about the buyer.
Most new bitcoin users have to give away their identity when buying their first bitcoin, and some of them are worried if it's even legal to use bitcoins.
So my guess is that anonymity makes ATMs quite useful.

If it goes life, add: offlineaddress.com

So old, yet it feels like it was written just a few years ago.

Browser plugin solution tied to web site seems like a nice combination.
...

EDIT:
We have to decide on common solution.
Check out canton's proposal below.

Hi, I'm developer of offlineaddress.com.

To be able to develop secure bitcoin services we need a way to allow developers to prove security of their sites, without hurting usability for average bitcoin users.

Validating service could be generalized and also useful to sites that aren't related to bitcoins.
It might sense to contact:
 - GitHub.com
 - EFF.org
 - TorProject.org
because it seems to me that they might want to solve similar problems.

Solution could be:
 - third site, as described by canton (general, or specific to bitcoin sites).
 - browser plugin that compares checksums automatically on each visit, for sites with specified meta tag with link to the source.