Well to be honest - you have a good concept with the live CD and so on but then you should be so consequent and use that only for creating wallets and nothing else. +_+
And as you see you should always used a proper password even if it’s only temporary.
We had already a case where somebody had his very low-level-secure password brute-forced and lost 6M xem…
Yes this was my fault, I know. I didn’t browse the web while having my wallet open. All I did was to find out the wallet address for the DIM Ico. But I must have stumbled upon the malicious website in the process.
That sucks… still, for me 5687 Xem was much money…
I will still try to find the vulnerability in the NanoWallet and the attackers website. Because everyone is at risk. If they have your wlt-file, they will try to crack it, no matter how good the password used.
Every hacked / lost xem hurts doesn’t matter how many. 
As far as I know you can only crack (decrypt) a wlt file with the password. Which boils down to brute forcing the password or obviously utilizing a key logger.
Anyways I hope you might remember the malicious site. At least this is a warning for others not to do the same mistakes.
I hope so as well… I will keep you all updated!
If I see this correctly, other online services could extract variable values from the local storage, presuming they know the key value.
@Saul thought this might have some importance…
r3n3 : there is a security fix pending, but the details of exploit haven’t yet been published, devs know a bit more, NEM Beta 0.6.91
We have played around a bit.
CHROME and SAFARI allow the following proof of vulnerability:
index.html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Show Browser LocaStorage</title>
</head>
<body>
<pre id="result"></pre>
<script src="index.js"></script>
</body>
</html>
index.js
document.getElementById("result").innerHTML = JSON.stringify(localStorage);
If you feel your login password into your Nanowallet may be too weak (bruteforce-able) - it does not help to export the private key, and re-create a new wallet via “Sign Up” in the Nanowallet.
This is because the old localstorage may already be stolen and worked on by brute-forcers.
Mitigation: Transfer your XEM to a new NEM ACCOUNT which resides in a secure wallet.
For some time, we may have to live with the fact that the browsers’ localstorage is not “secure”.
Greetings,
Rene - LuxTag powered by NEM
[Thanks to @musdom (Developer at LuxTag) ]
Can someone explain how anybody can steal the localstorage on ubuntu live?
If you happen to land on a malicious website with your wallet loaded and not yet purged.
My understanding is that they already have stolen many wlt-files that way. brute forcing is just a matter of time unless a password as good as the private key is being used. my weak password took them 5 days.
So the lesson learned is…
Never browse another site while having an unpurged NanoWallet open.
In my case an expensive lesson, but hopefully other people will benefit from that.
I might be missing something but…
Local storage is domain specific. I’d argue that it’s not as easy to exploit in the wild when you don’t have everything running locally.
If you have nanowallet open and go to https://someothersite.com, the js on that website will not be able to access localstorage of nanowallet because it is on a different domain.
So XSS being involved makes a lot more sense, though I’m not sure how they would have pulled that off. To me this looks like they were targeting nanowallet specifically since it’s unlikely that some generic XSS that happens to be reading local storage happens to be operated by people who know what they got their hands on. If it is targeted it is likely a site that nanowallet users are likely to visit with nanowallet open though I in no way want to accuse anyone (if we have all the possible websites it’ll be relatively trivial to figure out which one it was).
All in all everyone can put their panties back on. Local storage is not in and of itself insecure plus a strong password seemingly would have mitigated this attack entirely.
That’s what I think as well… I still have to reconstruct the possible sites that I have visited. I might find something. But if I were the attacker, I would probably start out with domain names similar to the official Nem sites. That way the chances are high that, by a mistype in the address bar, the victim visits that site with an open wlt-file in their local storage.
I will still try to evaluate the NanoWallet code and look for that XSS vulnerability. Maybe an unsafe evaluated JSON.
I’d run an ico and give 10% bonus to all XEM investors and tell them to only use nanowallet 
I’m not making a serious allegation here, I’m just joking. I doubt it’s dimcoin.
My wallet pass should slow them down a bit, at least 10000 years:D
It must be at least as secure as the private key, to not pose an additional security threat to your wallet.
Hmm but the new 1.4.0 standalone version shouldn’t have that ‘vulnerability’?
I asked QM to look into this. He told me that the wallet was created with a brainphrase “12345q” which a bot can scan for and then clean the account.
So the wallet wasn’t compromised, nor the server, no the computer. The account was made with a brainphrase that is very easy for a hacker to brute force.
Remember, you brainphrase = your private key. Please use very long pass phrases when making a pass phrase wallet.
also, we all feel for your loss. we hope that somebody else can learn from this thread and be safer.
Hi,
There is no known vulnerability in Nano Wallet and I don’t think it is possible to access the local storage content remotely.
The wallet created in this case was a brain wallet with a weak password, that is the problem.
There is people that scan for weak brain wallet and you got unlucky 
Thanks for the clarification.
