Thank you for formalizing this problem, many of us are indeed stressed ;)

Unfortunately, I cannot recreate the situation, as I participated in the Pre-Sale event. I've got my ethereum_wallet_backup.json and my notepad document with password on it. It is a very simple password, yet has special characters as per the requirements of the presale.

I've been running every type of password cracker there is on this wallet. Currently heavily invested in Hashcat.

I suppose the big question I'd like answered is: Does this bug change the hash value because of the input error?

I would suspect it does. If a character as ! doesn't get run as that, it would completely change the contents of my .json file to something different. Therefor, my Hashcat will never return as positive. My entire wallet file is now useless, isn't it?

Unless we can figure out what the ! character has become, then I can retry running my Hashcat with a formula.

Do you still have access to stage.ethereum.org's code? Is there a way we can reproduce the pre-sale problem? Sincerely,

anormore on 8 Jan 2018

Please reference this bug report, as you can see, it has existed for a long time with PreSale wallets.

https://github.com/ethereum/mist/issues/182

anormore on 8 Jan 2018

:+1:

oldmate89 on 8 Jan 2018

Hey, thanks for the heads up, is "wallet creation during onboarding" supposed to describe wallets that were created while nodes were still syncing? That's what I did and I've seemingly got the problem aswell. I tried installing Mist on a rather old netbook which never managed to finish downloading all blocks (maybe not enough RAM). As the netbook was obviously too slow, I tried opening the keystore file with myetherwallet (there's not much on it, but still…), then noticing my password wouldn't work. Could it be because it hasn't finished syncing?

0x7969 on 9 Jan 2018

👍2

Hi Ethereum Team,
Thanks for giving us an official update.
@evertonfraga to help you gather info on #3539, my keystore files were created 6/16/2016 and 6/24/16. The password contained multiple special characters which has already been discussed as an issue. The last transaction I was able to send out from the wallet with the same password was 552 days 4 hrs ago. Hope this helps with identifying the problem.

Specs:
MacOS High Sierra 10.13.2, Keyboard Language: English, Running Ethereum Wallet 0.9.3 synced with light client.

funsh1ne on 9 Jan 2018

@funsh1ne would you please try this? https://github.com/ethereum/mist/issues/982#issuecomment-247409749

evertonfraga on 10 Jan 2018

⚠️ ⚠️ Calling all users that can't access their accounts. ⚠️ ⚠️
Please help us get more structured information about your "Wrong password" issues.

https://goo.gl/forms/jznmHV6Fpui7Ijds1

evertonfraga on 10 Jan 2018

@anormore I'll try to find the presale wallet generator.

evertonfraga on 10 Jan 2018

I followed the instruction from the google form and after 6 month I could unlock my account!! I used the geth account update methode, I don't know if that's normal behavior or not, account 0 and 1 had the same address. But I'm sure it's not good to also have two separate keystrore files for the one address, which i had. My password that didn't work inside the wallet unlocked one account here, I changed the password and after that I was able the send the coins from myetherwallet. Thanks for the help!

frufru99 on 10 Jan 2018

🎉4

I've been chatting over at the HashCat forums, where Philsmd has given a great amount of insight in to this, from an outside perspective.

https://hashcat.net/forum/thread-7181-post-38590.html#pid38590

Here are the cliffnotes:

It is true some users reporting this issue have infact found their password afterall
If it is indeed Ethereum wallet generation that is bugged, there is no sense in running Hashcat / Ethcracker
If this is infact the case, we should build a case study and determine a repeatable approach to creating the bug to understand it, after which, we can build a solution to solve it

Thanks @evertonfraga for digging that out. I'll spread the word about your Google Form.

anormore on 10 Jan 2018

👍4

Maybe the problem only happens when the funds have been transferred to the wallet, a rewrite of the UTC file ? Just an idea. The only thing I cannot reproduce is the money transfer and maybe cannot reproduce the issue because of this.

sebd-davra on 12 Jan 2018

👍2

@anormore have you tried importing from C++ ETH? What is the "version" of your keystore, as we can see on the issue below

Follow this issue: https://github.com/ethereum/mist/issues/2097

evertonfraga on 14 Jan 2018

Well, I'll have a look -- but it's a PreSale wallet from August 2014. I've tried the Kraken presale importer, myEtherWallet with no luck. But I'm not really certain what tool will FOR SURE open my wallet. I'll check your solution in #2097

anormore on 14 Jan 2018

I'm not sure how to proceed on determining version. Would you like me to submit a copy of my wallet to you?

anormore on 15 Jan 2018

I too am having the same issue. I have tried on both MEW and Kraken. I was using an English (Australian) keyboard layout.

I will try importing on Geth, however my understand of Go language is limited. Are there any details instructions available that anyone would recommend?

oldmate89 on 15 Jan 2018

A user managed to recover his password playing with different types of accentuation characters. Mind the differences between ^ and ˆ and consider it on your password recovery process.

From a Mac computer:

Shift + 6: ^
Option + i, Space: ˆ

> "^".charCodeAt(0)
> 94
> "ˆ".charCodeAt(0)
> 710

In Windows computers, I believe the similar result can be accomplished as:

Shift + 6, space
Shift + 6, [type the next, non-vowel character]

More info here: https://github.com/ethereum/mist/issues/2077#issuecomment-310897624

evertonfraga on 15 Jan 2018

Hello,
Before about one year I installed wallet version 8.1 and blockchain was about 120gb.I made password and wrote her on paper.Also I transverred 1 eth in wallet and with that password I sent them back on my poloniex account.Everything was great and success.After that I made several transactions in my wallet and everything is visible on blockchain.After few months I bought new laptop and installed wallet again with my wallet key.Now when I try to transwer my eth to any exchange I get message that password is wrong.
I see that my blockchain is about 23 gb now,If that can be problem?If that is problem,how to get blockchain with 120gb?

SasaETH on 15 Jan 2018

Hey @evertonfraga, I used the Staging.Ethtereum website to create my wallet. I'm wondering what OS and characterset your computer used? I've got a pretty solid Hashcat job running now, and can load in special characters.

So, what are the outcomes if I had entered !Password1 in to your website from a Windows / Mac computer? What if my keyboard is set to French/English, is the ! treated as a different character, which generates an entirely different wallet hash?

anormore on 15 Jan 2018

@anormore
The use of ! might suggest string truncation, but unlikely to have happened during presale, only when created via stdin.

Associated risks with use of the specific ! character between languages are low to unknown.

evertonfraga on 15 Jan 2018

@evertonfraga

Tried to truncate the password too, tried both, by including ! and without it . :/
No cure. Any other known issues with $ # or @ ?

pavneet09 on 15 Jan 2018

I have only alphanumeric characters and I copy pasted from keepass then this method is not working.

sebd-davra on 15 Jan 2018

@evertonfraga May I ask what work is being done at Ethereum to rectify this issue? How serious is this to your organization? Are you simply collecting data, or is this a larger issue at the office? It's nice to see this is an officially recognized issue, but what does that mean for us and the community?

anormore on 15 Jan 2018

👍3

@evertonfraga, Have you ever tried to reproduce issues with empty Mist password when Skip button used? Is it possible with old versions of geth/mist (May release 0.8.10)? Can you run a round of tests for this case? I have been running the hashcat tool for about two months but still without success.

alxlv on 15 Jan 2018

@anormore I am collecting and organizing the information that was spread throughout various issues. I've read the entire history of people with password issues, and I've raised some questions, which I put on that form, which I consider the best way to do so.

@marcgarreau and I have conducted several tests, trying to reproduce this issue but couldn't until now. The existence of a software issue is still unconfirmed, meaning that there aren't any successful reproducible steps, neither from the community nor the team. We're relying on reports, from different classes. Some examples include:

People having problems with presale wallets that were created even before Ethereum Wallet was released.
People having problems with accounts created within Wallet.

I believe this is a tough subject with several other classes of issues, and I want to stratify, and ultimately, solve them.

We'll use this place as "rally point" regarding this issue and keep you informed of our efforts.

evertonfraga on 15 Jan 2018

👍6 ❤4

Thanks @evertonfraga this statement alone makes me feel less stressed.

anormore on 15 Jan 2018

I am sorry to write in my role as IT Delivery Manager here. Not to abuse people and slow down the positive input here but this is a MAJOR issue that should have high priority and is OS type, Mist, Wallet and Geth version independent. Mist Version 0.9.2 also creates this issue. I am missing a taskforce here. High impact on future usage of Ethereum it's blockchain. Two years and no detailed test reports ? How many people are involved ? Why is this not on the agenda of the Ethereum Core Devs Meetings.

r3lax3d on 15 Jan 2018

👍4

@r3lax3d

Were you able to recreate this issue in any of the versions of mist after the first attempt or the original locked out account? Or are still able to recreate it?

pavneet09 on 15 Jan 2018

@pavneet09
Hi there, After a hectic day of troubleshooting and try-outs I will backup files wich are created and still on disk from first installation on the 4th of Nov. 2017. And I will start tomorrow with a clean sheet more structured way to either solve it or recreate the issue. Keep you informed and please do a recap of the type of files you are interested in. Thnx in advance.
P.s my env. is Fedora 27

r3lax3d on 15 Jan 2018

I have been trying to recreate the issue on pretty much all available versions of Mist just to send the input to the Dev team. As mentioned earlier the team has not been able to recreate the issue, and after being on these password threads for months, it seems no one has been able to recreate it after the first off chance which makes fixing it all the way more difficult.
I understand the frustration as I am in the same boat as you, but lets hope one of us is able to recreate it, will go a long way in being able to getting this fixed! Good luck!

pavneet09 on 15 Jan 2018

👍1

I agree. Thats why we have to reproduce it exactly. I will start a clean install. Create the password while the blockchain still isn't synced and so on. Is there a possibility to create more debug info ?. We see. Thanks so far !

r3lax3d on 15 Jan 2018

created the address ethereum on June 11, 2017 in the ethereum wallet. Before translating all the funds from Poloniex, I made a test transaction. The password worked. it was July 30, 2017, the password was immediately written down on paper.
Now installing on a new system, the wallet says that the password is not correct. Also does not work through the site myetherwallet.com.

KuzmichE on 16 Jan 2018

👍1

Isn't it more efficient to reverse engineer the passwords in stead of trying to reproduce the problem?

ontheronix on 16 Jan 2018

👎2 🎉1

@ontheronix no -- We need to reproduce the problem, in order to reverse engineer a password. I'm currently running 50 billion password combos a day. Semi-blindly.

anormore on 16 Jan 2018

@anormore how are you running 50 Billion combos a day? I assume it is pre-sale and not a Mist Scrypt encrypted wallet?

ethtester on 16 Jan 2018

Running a GTX 1080, we've got a decent thread started here: https://hashcat.net/forum/thread-7181.html

I was wrong, not 50 billion, but 34,359,738,368 is pretty close ;)

Yes, Ethereum Pre-Sale wallet from August 2014.

anormore on 17 Jan 2018

I am running Mist 0.9.2. There was never a question about a password. I have a lot of wallets for all kinds of coins and did only set a password when it was required. For the Mist wallet it was not required (or empty string). I am 100% sure, since I created the wallet only 2 months ago. Also I am using the same password on all my coin wallets. This password does not work either.

Klusjesman on 17 Jan 2018

👍2

i have the same issue. I have two accounts in my wallet with same password. main wallet is ok. but account 2 keep saying wrong password.yet its has the same password as account 1.
For me its only a small amount. (0.09) but i really feel for people with larger amounts.

7iain7 on 17 Jan 2018

👍2

Hello,
Before about one year I installed wallet version 8.1 and blockchain was about 120gb.I made password and wrote her on paper.Also I transverred 1 eth in wallet and with that password I sent them back on my poloniex account.Everything was great and success.After that I made several transactions in my wallet and everything is visible on blockchain.After few months I bought new laptop and installed wallet again with my wallet key.Now when I try to transwer my eth to any exchange I get message that password is wrong.
I see that my blockchain is about 23 gb now,If that can be problem?If that is problem,how to get blockchain with 120gb?

SasaETH on 18 Jan 2018

👍1

Although it's usually OK, sometimes if you copy and paste a password it is possible to copy white space at the end of password. Try manually putting the password in if you have not already tried.

7iain7 on 18 Jan 2018

This a long shot, if you have use the `@' in your password try using %40 instead of @.

7iain7 on 18 Jan 2018

👍1

No kiddin? I'll try this for SURE.

anormore on 18 Jan 2018

And If we have only alphanum characters (hex characters abcdef0123456789) but a 64 characters password, what we can do ?

sebd-davra on 18 Jan 2018

The is a small possibility @ got convert to %40 https://stackoverflow.com/questions/9193078/converted-to-40-in-httppost-request

7iain7 on 18 Jan 2018

@Sebd-darva that sucks man, that's a LONG password to try and crack. I'm taking offers to try and crack passwords, I've got everything setup smoothly and am pretty adept at it now. If you're confident you don't have special characters, and you know it's 64... It seems likely I can help you. Maybe..

anormore on 18 Jan 2018

👍1

Ok if you can help me :)

sebd-davra on 18 Jan 2018

Send me an email at [email protected]

anormore on 18 Jan 2018

Thanks @7iain7 - that is really helpful. Has anyone used this with their wallet to resolve their wrong password issue?

Applying the same logic - see attached link which would show conversion of other characters:
https://www.obkb.com/dcljr/charstxt.html

oldmate89 on 18 Jan 2018

I believe if it was an issue of conversion then the whole string would get converted instead of just the special characters.

Having said that, I just tried the options of using all terms as HEX, just the special character, each special character separately, but unfortunately that did not work..

pavneet09 on 18 Jan 2018

Would you just try one more thing please. Only change the @ to %40 and leave the rest if the password as is.

7iain7 on 18 Jan 2018

Just tried that too, unfortunately nothing changed and the yellow wrong password box continues to haunt :/

pavneet09 on 18 Jan 2018

OK try this put password in then hit the space bar once and try.

7iain7 on 18 Jan 2018

Didn't work, just to be extra sure, Ill just add the hex to my ethcracker and see how many more variations I receive.

However I'm really impressed by 35billion combinations using hashcat in a day, @anormore , can you increase that if you ran it over a few gpu's?
I have about 120 RX 580's, I don't mind taking them off their usual task for a day or two just to crack this already!

pavneet09 on 18 Jan 2018

@pavneet09 Hashcat is vastly superior to Ethcracker, but Ethcracker is less complicated. I'm not sure if you can parallel the application, but there is device selection -- so maybe? Head to hashcat to see.

anormore on 18 Jan 2018

👍1

We really need some one here to crack a password, and let us know if we're all crazy tin foil hatters -- or infact there was something complex and buggy... :/

anormore on 18 Jan 2018

@evertonfraga How can I generate a fresh presale wallet? Even if it doesn't sync to the blockchain? I'd like to just verify my input/output models...

anormore on 18 Jan 2018

I have been using hashcat for month but still without success. I started to crack from 6 letters password (digits, alphas and special characters), do not know how many letters it has because I did not set it. It's possible to run hashcat with using CPU, GPU or both. For example speed on my AMD Ryzen 1700x CPU is 20 h/sec. Here is my command string (windows 10):

hashcat64 -m15700 -a 3 -D 1 --self-test-disable --session brute_force *$ethereum$s*n*r*p*salt*ciphertext*mac* --status --status-timer=5 -w 3
a?a?a?a?a?a

Overview:

https://stealthsploit.com/2017/06/12/ethereum-wallet-cracking/

The speed calculation:

https://stealthsploit.com/2018/01/04/ethereum-wallet-cracking-pt-2-gpu-vs-cpu/

Shortly, you need a lot of computer power to crack without any information about password. Sad.

alxlv on 18 Jan 2018

Using hashcat is really not the answer here and just a possible solution.
The real approach is to run a debug on one of the existing clients that reported this problem.

Unfortunately I don't posses the skills to do that. Whoever posses them, please post a step by step tutorial an how to do it and post useful feedback.

TGM on 19 Jan 2018

👍1

@TGM I totaly agree with that. We need HELP from a DEV that can show us the debug methods and has knowledge of the password and encrypt code. And process flow. Why hiding ?
Is this the way Opensource communties work/communicate ? I hope not.

r3lax3d on 19 Jan 2018

Guys, I know hashcat usage is not a bug fix but maybe it may help someone to access to their wallet. I'm sure that's the problem 1 for most of us. As for me I did not set a password at all and would like to know more about password flow too.

alxlv on 19 Jan 2018

This from anther tread on this subject "For a friend of mine I've been trying to crack his wallet for days, but found out that Mist simply replaced his "faulty" character for a space. Worth a try!"

7iain7 on 19 Jan 2018

Ethereum uses encryption algorithm keccak256. Shoot if not actual anymore..

https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated

and to demotivate hacking if during the generation process / bug will change a 'Bit'

https://ethereum.stackexchange.com/questions/11572/how-does-the-keccak256-hash-function-work
https://www.slideshare.net/RajeevVerma14/keccakpptx

https://en.wikipedia.org/wiki/Message_authentication_code

Next... how handles Ethereum code (I think about the process just before Message to hash) this during installation of the software or importing your json in another environment / software version

https://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key

P.s and i keep repeating that the bug has nothing to do with special characters in a password. The proof is my own password letter/number lower case. And from others.

r3lax3d on 19 Jan 2018

👍1

The bug has nothing to do with special characters I do NOT have any special characters.

sebd-davra on 19 Jan 2018

🎉1

Mist is essential a Web browser with a wallet. In earlier versions of mist did it convert an ascii to html when the password was created?

7iain7 on 19 Jan 2018

https://web3js.readthedocs.io/en/1.0/web3-eth-accounts.html

https://github.com/ethers-io/ethers.js/issues/66

Disclaimer: Digging into the code and try to understand. Not saying I am on the right path. But highly interesting ;) Hope to give some DEV's a rope or a lift whatever.

r3lax3d on 19 Jan 2018

👍1

This is worth a try ascii to html converter: http://succulent-plant.com/toys/asciitohtml.html

7iain7 on 19 Jan 2018

@7iain7 Mist has never converted to htmlentities (é > é) as it uses the default utf-8 encoding.

evertonfraga on 19 Jan 2018

👍2

@7iain7 We have to test every input we give to eachother. So i tested it but negative here...

r3lax3d on 19 Jan 2018

Hi everyone -- we need to STOP GUESSING at this, or we will never get it.

We need to re-create a Mist invalid wallet error and from this, we can identify how to crack it. If I have time this weekend, I will look at creating a Geth script to reverse brute force wallet generation, and see if I can trigger the error.

Speaking with the mods of Hashcat, this is their perspective too. We can sit here and debate special characters or entities, but first we must identify the problem.

anormore on 19 Jan 2018

I agree. I'm currently building a clean test bed to install my original mist wallet (0.3.9) and will attempt to re-create my issue which was an automatically created Etherbase wallet that did not prompt for password.

ethtester on 19 Jan 2018

Currently running 0.9.3 the wallet was created either using this version or 0.9.2 cant recall which exactly. Password is 100% correct and contains no special characters, just uppercase, lowercase, and numbers. Password was written down in a txt file as well a physical paper, both match and am still getting a wrong password error when trying to send funds. This is pretty ridiculous.

shopifymatt on 19 Jan 2018

👍2

@shopifymatt Try MyEtherWallet.com to see if it unlocks

anormore on 20 Jan 2018

@anormore Gave it a shot, no dice. Same wrong password error :(

shopifymatt on 20 Jan 2018

@shopifymatt Welcome to the club. We have a good community here. We're currently investigating weather or not we're dumb and screwed up input of our password, or there is some bug with Ethereum. It's 50/50. We have arguments for either side, with no definitive answer. Maybe in the next week or two some work will be done towards determining this. Until then, welcome. Grab a chair and sit. Patience is your friend here. (Besides, ETH is going up anyway.)

anormore on 20 Jan 2018

@anormore so are all those juicy alt coins I was gonna buy with my eth haha, oh well. As long as it eventually gets fixed I don't mind.

shopifymatt on 20 Jan 2018

I have a backup of the %appdata%/Mist folder that was used when I created my now unaccessable wallet. Could this be of any help?

Also, has anyone tried recreating the bug by copy/pasting a password?

ontheronix on 20 Jan 2018

@imanik92 Hello iman, before I email your contact. How many characters was the password and did it include numbers and special characters, also what was the version of mist used to create the wallet?
Thanks

ethtester on 20 Jan 2018

👍2

I wouldn't suggest giving your keystores and passwords away. It's a desperate measure. Learn and invest in Hashcat yourself, and do it yourself.

anormore on 21 Jan 2018

I wouldn't ever. I know this is a scam testimonial..

ethtester on 21 Jan 2018

I have lost bitcoins in mybitcoin online wallet scam in 2011.Then Mtgox, then 50btc mining pool. Trust NO one where your cyrpto coins a concerned. I cannot stress this enough.

7iain7 on 21 Jan 2018

@anormore @ethtester @7iain7 after all the proof i provide its still not good enough for you, just be happy for me I guess and move on. That simple. Wanna help both parties.

imanik92 on 21 Jan 2018

👎1

This thread is deteriorating Please stay on topic of the Ethereum BUG

Wallet recovery services should not be discussed here, please PM users if you wish to do so.

anormore on 21 Jan 2018

👍3 👎1

Hello all, just to reiterate this is not a thread of lost or forgotten password, there are many who believe a password was never issued and some even having the screenshot of the moment of password creation (such as me) as well as those who wrote it down or copy pasted it immediately.

We believe something went wrong somewhere and we are unable to access the wallet again, the devs are here to help but this is neither a time for blame game, nor the time for senseless discussions.

Kindly try to recreate the problem at your end by following the exact steps, even though we have the devs attention and their willingness to help us in their entirety but this is not an abnormality till it is replicated, which neither us or they have been able to recreate.

We do not wish to create this as, one of many threads for services or hacks or recovers, let us kindly try to recreate the issue or solve it on the whole and keep the discussion only substantial. Emojis help communicate way better!

pavneet09 on 22 Jan 2018

👍3 😕1

@pavneet09 The problem with attempting to recreate this issue is that it only presents itself when attempting to send funds. I have no interest in depositing more funds into yet another wallet to have those get locked up due to a bug either.

My exact steps were not exactly ground breaking and I doubt most others were either. Create wallet > Setup wallet >Deposit ETH > at later date attempt to withdraw ETH > Enter password > Get told password is wrong.

There isn't much room for error nor a need for replication, there are people who have literally taken screenshots to confirm they have the right passwords upon sign up, or people like myself who have written them down manually, and others who use the same password for everything all having the same issue.

If you are willing to lose some ETH to test this out, more power to you. I would rather not lose more money however, replicating the most basic functions of a wallet. I get what you are saying but, there is a limit to how much of the effort needed to solve this falls on the users, and I believe we are well past that point.

shopifymatt on 22 Jan 2018

👍4

@shopifymatt Im in the same boat! :)

I created the wallet address with no intention of withdrawing it in the near future, until one fine day I tried to transfer just a bit to be told the password is wrong. Unfortunately there is no other way for us to help other that contribute as much as we can to solve the issue.
And yes, I am one of those who has the same password of all different alt coin wallet address, plus I take screenshots, so I would've thought there would be very little margin of error!

pavneet09 on 22 Jan 2018

👍2

Hi @pavneet09
You are totaly right. And thank you for the comment. But basically 'they' want front-end users to do 2th and 3th line technical stuff. We have to reproduce it. Many issues in this long sad very sad issue tracking list already show the steps.

Reproducing the error is very time consuming. And with all respect, I am IT specialist but not a DEV @ Ethereum and thats why i am also looking at a black box untill we see jawdropping help from DEV's. And I went deep already...

Provide a hand-out to reproduce the account creation step by step (command-line)
Provide a hand-out to collect debug/trace info
Create a hackinton. Use the crowdforce of open source where we can participate
Start thinking about a workaround - for example a smart contract to give people their ETH back
- A win win situation https://github.com/ethereum/EIPs/issues/156 (defect of the Ethereum network)

@shopifymatt - same same here....

(don't become the LEADER (of forgotten bugs) from the most promising enterprise software of the future) ;) ;)

r3lax3d on 22 Jan 2018

❤6

Thanks everyone for your recent comments to get this issue back on track.

anormore on 22 Jan 2018

👍2

@imanik92 @anormore The warnings about sharing keystores are clear now, the discussion can stop here. The more important thing is to know what the cause of the not working password was.

ontheronix on 23 Jan 2018

👍1

And I would like to see a reaction on my request(s) from Ethereum team.

r3lax3d on 23 Jan 2018

@imanik92 From the discussion from Reddit, we learn the user simply forgot their password, building evidence for this bug.

"The password was close to what I had thought it was. I assumed there could have been a problem but I wasn't sure where I could have made one. After trying many passwords myself I was certain that it had been scrambled or maybe I didn't use my 3rd grade taught keyboard hand placement I learned so many years ago and mucked it up. When I got the password back there was no special character, just my forgetfulness."

That means something for us all here, and that we should not make angry demands to the Ethereum team -- as there is a chance that we all have forgotten our passwords, and this situation is our fault.

No one has yet to create a repeatable bug report for them.

Many people claiming the bug have found their password.

At this point, in my humble opinion (that may yet be wrong), the evidence really supports the conclusion the Ethereum bug does not exist. Believe me, I want a magic solution and to point fingers too, but that won't help you recover your Ether.

@imanik92 I still do not encourage sharing your keystore. But this isn't the place to discuss recovery services, we need to keep this chat here VERY clean and concise if there is to be hope of discovering a bug.

I personally have created 100 wallets via Geth, and all 100 wallets opened with out a problem.

anormore on 23 Jan 2018

👎2 👍1

We do not forget our password ( I copy pasted from keepass) ... the bug is existing but we cannot reproduce it because we don't want to transfer any money in the ether trap...
It's not because people forget their password than the bug does not exist.
@anormore don't try to get the wallet of the people too...

sebd-davra on 23 Jan 2018

👍1

@anormore I won't argue that there definitely are cases of people who simply forgot their password, and for them the recovery services are risky but great, if they work.

The problem is there are plenty of us who can say with 100% certainty that the password was not forgotten. Creating wallets is not the issue, that can be done no problem. The only way to replicate the issue is to actively have ETH in a wallet and attempt to send it as that is the point in the process where the bug (wrong password regardless) would arise. I don't know about anyone in this thread but, I'm not willing to throw money away to try and solve an issue that is in the developers realm of influence.

shopifymatt on 23 Jan 2018

👍3

We don't need ETH for testing the password or reproduce it. ETH value in a adress is something what has no effect on the route cause. Just create a new installation and create an account / preferable in my situation while the blockchain is still synchronizing.

@anormore You are presuming a lot for others. I respect your input and stay on it but, It is a well known bug and Ethereum team is not actively working on it. Atleast we dont see it. And reproducing steps are already two years provided in a front-end user way.

r3lax3d on 23 Jan 2018

👍2

In the Geth command line, you can unlock your wallet without having to do any transaction:
https://ethereum.stackexchange.com/questions/4157/how-to-unlock-the-account-with-geth

ontheronix on 23 Jan 2018

👍2

You do not need to transfer Eth to find if a newly created account is working or not. You can simply go and try to unlock it using Geth. Just like @anormore I too have created many accounts, only to have them unlock simply.

pavneet09 on 23 Jan 2018

👍1

Hello all.

I think we should be clear that offering your keystore and password with this as an active bug is foolish.

Regarding my post that a user had recovered a password by offering their keystore and password was simply indicating that there was in fact a user error.

As people here are taking a 20% commission, it is considered a for profit venture. Advertising dangerous services such as giving away your keystore should be avoided here, as we are trying to solve a bug. We should stay on topic. As you can see, we are quickly falling off topic from identifying the bug.

We need to be able to clearly and concisely identify what causes the bug. It seems that users here are saying that when Ether is deposited in the wallet, the wallet becomes in-accessible with an invalid password.

Previous to this, is the wallet accessible?

We should be able to ask the OP of this thread to verify this bug over a large test bed of wallets and determine the outcome true or false.

Is this reproduceable? If so, let's compare what is happening and find a solution. I would imagine Hashcat would be involved or some sort of wallet conversion script would be executed.

Anger will not get us any further ahead. It is still at this time NOT clear that this is a legitimate code bug, unless some one can do a Youtube video showing them 3 wallets in a row that 'become corrupt', there's not a lot to go on.

I will not pretend I speak for the Ethereum developers, I too am frustrated by their lack of communication on this issue.

We are a community here, of lost passworders. Some of it MIGHT be legit, so prove it is legitimate. In many cases, the user infact forgot their password. I'm fairly certain I have simply forgotten my password and am running Hashcat. I will continue to watch this thread, but will refrain from commenting any more.

I think this small community here on #3513 have done a fair share of research, and should be recognized and officially responded to by Ethereum.org, before any more anger, frustration and action is taken.

anormore on 24 Jan 2018

👍3 ❤1

@marcgarreau @evertonfraga Now might be a good time for Ethereum.org to step in. Things are getting.... tense.

And understandably so.

anormore on 24 Jan 2018

👍2

@anormore and others that are using Hashcat:

Have you tried adding control characters to the dictionary, on the password boundaries? Examples include:

Carriage return (CR) \015
Line feed (LF) \012
UTF-8 Byte order mark (UTF-8 BOM) U+FEFF at the beginning

evertonfraga on 24 Jan 2018

👍3

Hi EV
Thanks very much for this.

I am using hashcat however have not tried using these control characters. I will be honest - I am not familiar with these character sets. Are you able to provide some further insight regarding this and I can run these in my rulesets.

Thanks

oldmate89 on 24 Jan 2018

Thanks @evertonfraga I'll try adding this in on tonights batch.

@oldmate89 Head to Hastcat, I've got a good discussion started: https://hashcat.net/forum/thread-7181.html

anormore on 24 Jan 2018

Hi guys, I'm in the same situation.
I was using, an ethereum wallet created in 2016 and I have never tried to use it (only input transactions).

Now, MEW and geth ask for a password. A was believed that there was no password, but maybe I was wrong.

If there is a password, I use always the same password to lock all my wallet, so I think it's not a "forgotten password" problem (but I can't be sure of that).

I have tried pyethrecover a little, but with no luck.

I now would like to help to debug it, if I can...

ceric35 on 25 Jan 2018

👍1

@evertonfraga Still trying to figure out how to run a script with these characters, one of the mods got back to me, and I'll re-run my scripts with it now:

https://hashcat.net/forum/thread-7181-page-3.html

For all those interested in running their own hashcat instance (@ceric35 )

anormore on 26 Jan 2018

@evertonfraga Now that I'm learning so much about this problem, I think this image can illustrate how this problem might occur:

If my memory serves me correctly, I did infact use notepad++ to "generate" my password. I very likely copy and pasted it. As you can see the last two characters are line returns, and are 'invisible' to the screen.

So, @evertonfraga proposes that we try cracking/entering the password with these characters. You can achieve this by copy and pasting in the EXACT same way you created it.

This makes me wonder about those guys who created their wallets from the Mac password keeper thing. If they copy and pasted their passwords out of that, I wonder what extra crap also got carried over.

I know this is a real issue in a lot of software (especially with Macs). We run a MySQL + PHP system and work, and people who paste from Mac lose all their formatting and stuff. It wasn't stored in the database properly. So this kind of problem IS very real.

It is my sincere hope this is a step forward to understanding this bug!

anormore on 26 Jan 2018

👍3

Here's another illustration of how your password might get screwed up. In this case I made a password with some extra lines above and below, and added a space.

Oh shit -- it's even possible there's a space on the end of a password!

I've got a pretty sick Hashcat script running now. But none the less, I think I should be able to generate a purposefully "broken Geth account" now by making sure these characters are in my clipboard, generating the wallet, stripping the characters from clipboard, and then trying to open.

This might be able to replicate the problem.

anormore on 26 Jan 2018

👍2

Great work so far! I also remember copy/pasting my password into Mist, because I wanted to be sure I wrote it correctly (in the absence of a 'show caracters' option).

ontheronix on 26 Jan 2018

👍1

I will do some work this evening to see if I can 'break it' and reproduce this bug! From here, it should be rather trivial work to take your password, throw it in to Hashcat, Ethcracker, etc and determine for yourself what the password is.

Stand by for hopefully a really great result -- or nothing at all. I suppose this is how it goes...

From there, I'll try looking at the Mist wallet code to see how they take input variables. From this data we should be able to correlate the problems and come up with a solution in the Mist client itself, maybe.

anormore on 26 Jan 2018

Same problem here unfortunately.
I use same few passwords for most of my accounts.

I created main account with EthereumWallet and I'm sure the password I typed is known to me...
I'm not sure which version of EthereumWallet was used but geth that is still on my HDD is in v1.6.6 with geth.exe creation date same as my wallet creation date. Unfortunately personal.unlockAccount in geth 1.6.6 console won't work giving same annoying message "could not decrypt key...". There was ! in my password, so I guess there's a bug somewhere in the code while creating wallets. Tried empty password with no luck. I really hope this will be resolved somehow and few hundred $ that's on my account and few other accounts are not lost :/

It would be really good idea to actually ask for password every single time wallet is accessed... I wouldn't send any ETH to that wallet if I knew something was wrong with password.

zeezooPL on 26 Jan 2018

👍1

For @anormore and those who have a presale wallet:

Parity technologies have just launched a set of tools that can help on that
battle. Take a look and see if that helps.

“Tools

In addition to Parity, we provide tools such as ethstore, ethkey,
parity-evm. Each of these tools has been improved in various ways. ethstore
now supports the brute forcing of pre-sale wallets given a password list
for recovery”

http://paritytech.io/velocity-the-fastest-parity-released/
On Fri, 26 Jan 2018 at 20:21 zeezooPL notifications@github.com wrote:

Same problem here unfortunately.
I use same few passwords for most of my accounts.

I created main account with EthereumWallet and I'm sure the password I
typed is known to me...
I'm not sure which version of EthereumWallet was used but geth that is
still on my HDD is in v1.6.6 with geth.exe creation date same as my wallet
creation date. Unfortunately personal.unlockAccount in geth 1.6.6 console
won't work giving same annoying message "could not decrypt key...". There
was ! in my password, so I guess there's a bug somewhere in the code while
creating wallets. Tried empty password with no luck. I really hope this
will be resolved somehow and few hundred $ that's on my account and few
other accounts are not lost :/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-360920667, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC4BCJbLgq-sMZG-MeDkrr96qw-1rb_ks5tOk_xgaJpZM4RU48I
.

evertonfraga on 27 Jan 2018

👍1

I personally have created 100 wallets via Geth, and all 100 wallets opened with out a problem.

@anormore @evertonfraga This implies that the error lies at Mist, badly capturing the input?
@evertonfraga How many reports has the Ethereum team collected meanwhile? Are there any trends visible?

I have additional information for my report: the addres was generated with geth-windows-amd64-1.6.1-021c3c28 and Mist 0.8.10 (or 0.8.9 in the case that I accidentaly not used the latest version, but the chances are slim)

When I try to boot these old versions, Mist cannot connect to mainnet and shuts down with this error. How can I resolve this?

ontheronix on 27 Jan 2018

Mine was created using Ethereum-Wallet-linux64-0-7-4. I was not using command line geth at this time.

ceric35 on 27 Jan 2018

To reproduce this error, we should be able to take the following text and generate a wallet:

COPY AND PASTE:

Password5%

Notice how here there is a line return beneath Password5% -- make sure you copy it. So it looks like this:

We should then be able to PASTE in to the Geth wallet generation, which would then create a different wallet hash -- if this bug is indeed real.

This makes sense if you later copy and paste Password5% without the line return.

Or perhaps there is another character. Please begin testing this folks.

anormore on 28 Jan 2018

❤1

I am unable to reproduce my theory on MyEtherWallet.com.

I am unable to reproduce this theory with Mist, I was able to copy/paste the text and open a Mist wallet from MEW.

Geth remains untested right now... back later.

anormore on 28 Jan 2018

OH SNAP I CAN REPRODUCE IT!!!!!!!!!!!!!!!!!!!!!

I created this wallet with the latest version of Mist, 0.9.3.

Let's go through this one more time, with screenshots. My heart is pounding right now ahaaaa.

Create a textfile to store my password with line breaks

New wallet has been generated

Let's check this with MyEtherWallet.com

Let's press UNLOCK WALLET and see if it lets us in

CANNOT LOGIN: I HAVE SUCCESSFULLY SCREWED UP MY PASSWORD!!!! HOORAY!

--------------------------------------------

Let's try to access the wallet by copy and paste from NotePad with the line breaks

IT LET ME LOG

MAJOR VICTORY HERE GUYS! I think. Sorry for all the caps I'm insanely excited now. It does appear that if you have line breaks on your copy and pasted password, or you use some service like the PreSale wallet website from Ethereum.org and rules are not explicitly set to strip that extra stuff off the password - this WILL result in a buggered password!

@evertonfraga Please see if you can repeat these steps and verify I'm not insane.

PS: My donation address if you ever get access to your Eth is: https://etherscan.io/address/0xB5C88ce6CEd344609951eD6409dC35881Fd16996

Because I think I'm still pretty screwed as I probably DID forget my password in addition to this bug. FML.

anormore on 28 Jan 2018

❤6

OMG THATS AWESOME!!! So this means Hashcatting with x number of linebreaks to open up your wallet. I'll try the same with Ethcracker and report back! (My hardware is to old for Hashcat)

ontheronix on 28 Jan 2018

👍3

Just to follow up, when I copy and paste my password from Notepad++ to MEW, this is the visual:

Notice that even MEW has character inputs. And I'm about 95% certain that I generated my password in a notepad file.. but unfortunately I have lost that file. I personally might still be screwed, as I do need to use Hashcat to 'remember' my password combo. This this indicates a massive amount of hope for users who do have a copy and pasted password bug.

anormore on 28 Jan 2018

👍3

Bug: https://github.com/ethereum/mist/issues/3604

I believe this also explains why users suggest this bug 'only takes place when you add funds'. In my bug 3064 I describe that importing a wallet to Mist doesn't ask for a password, or send any type of confirmation that the wallet is imported. I mean, it does show up in the wallet software right infront of your eyes -- but I believe this is why some users perceive this problem the way they do.

It only becomes apparent to the user that their wallet is screwed up when they try to send funds out, because that's the ONLY time Mist asks for a password.

This of course is not the case, as you can see in my report above with password invisible characters are 100% able to completely fuck your wallet up.

anormore on 28 Jan 2018

👍3

Maybe the bug also happens without the special characters but it's hard to reproduce because of the random side of the generation of the wallet.

sebd-davra on 28 Jan 2018

So correct me if I'm wrong. But, because of a bug with the wallet code, our only recourse is to brute force crack our wallets?

shopifymatt on 28 Jan 2018

@shopifymatt Yes

alxlv on 28 Jan 2018

That is a really really shitty situation. I'm still not convinced this is the route cause, I did not copy and paste my password. I genuinely regret using this wallet.

shopifymatt on 28 Jan 2018

👍4

@anormore, great work reproducing it for newlines at least!

Am stuck with the same situation, as you can see from my previous posts. Was wondering, does hashcat work with wallets created with Mist? As I read that because it sets the Scrypt N ("n" value in json) to 262144 instead of 1024 of sale wallets and web-wallets, that hashcatting it is impossible due to RAM-limits on video cards?

JamesDall on 29 Jan 2018

Hashcat has recently added support for PreSale wallets. There are two types of main wallet types supported.

From Hashcat: https://hashcat.net/wiki/doku.php?id=hashcat
15600 | Ethereum Wallet, PBKDF2-HMAC-SHA256
15700 | Ethereum Wallet, SCRYPT
16300 | Ethereum Wallet, PRESALE -- (You need a new version of Hashcat)

My results with returned characters has failed so far But I will now try to decrypt with Hashcat and my previous example, and then provide the files are reference.

I have a suspicion that there are infact more characters that may be inserted in to the password, thus scrambling the wallet.

anormore on 29 Jan 2018

I was unable to start Hashcat on my GTX 1080 on a Mist 0.9.3 wallet. I guess the algorithm is indeed changed. I've referenced some guys from those threads here, maybe they'll join us for some support.

Apparently you can still do this on a CPU, but I guess a lot slower. 15kh/s on CPU vs 500 kh/s on GPU -- but hell you're closer than you were. Just slower.

So it does appear newer wallets are going to be a MASSIVE pain in the ass. It also appears pre-sale wallets will be less painful to work with -- however as they went through the staging.Ethereum.org website, we really don't know what extra garbage might have been picked up by their javascript / html form submit / backend systems. We need @evertonfraga for this.

anormore on 29 Jan 2018

I've attached here some broken files. The password for this wallet is:

Feel free to download the ethereum_v3_broken_wallet.txt and plug it in to www.MyEtherWallet.com

Go ahead and try this password: BrokenTest1!

It should fail.

You will have to download the ethereum_v3_broken_password.txt and copy and paste the entire thing (CTRL + A) ( CTRL + C) and then go paste it. Only then will it work.

ethereum_v3_broken_password.txt

ethereum_v3_broken_wallet.txt

@evertonfraga This is bug is repeatable, check it out.

anormore on 29 Jan 2018

👍1

@anormore Great work unearthing this bug! I will incorporate your findings into my hashcat/pyethrecover cracking efforts and report back.

branmcf on 29 Jan 2018

👍4 🎉1 😄1

Be interesting to find out the outcome to this apparent bug.
@anormore put in some good work here.
Would say deserves some ether for bug find.

On 29 Jan 2018 03:51, "Brandon McFarland" notifications@github.com wrote:

@anormore https://github.com/anormore Great work unearthing this bug! I
will incorporate your findings into my hashcat/pyethrecover cracking
efforts and report back.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-361133425, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ad6_lxY6gLmPmUsgo1ps6UJbHsdjGJm1ks5tPUA4gaJpZM4RU48I
.

tradexy on 29 Jan 2018

@JamesDall Can you provide your source? Because Hashcat takes the n value as a parameter.

ontheronix on 29 Jan 2018

Hi
My reaction to this "finding" is kinda two fold:

the problem with whitespace (in geth/mist) was already mentioned a couple of times on several geth/mist issues. It isn't really a "new" discovery. It's just one more person that was able to reproduced this.
It's actually very easy to test if the wallet can be opened with some additional whitespaces. You could just use any password recovery tool that supports this algorithm and feed it with the words + appropriate rules.
I'm not convinced that all the users affected by this problem copy-pasted the password with additional special characters (including whitespace). I think many just forgot the password, unfortunately. It's probably too tempting after you found a "password issue" of a software you used and blame it for your problem (instead of blaming yourself first, even if you are not 100% sure that the password is the correct one).
I know that there are several exceptions of this, i.e. a lot of users that have a screenshot/text file/password manager entry etc and are indeed 100% sure. Would be interesting to know how many of these affected users copy-pasted the password or used a particular operating system (e.g. macOS or windows).

on the other hand, I do not understand why the devs do not react accordingly (this is not an accusation, I'm just wondering why no obviously required changes are implemented at all). I would be so scared as a dev to hear stories like this, that I couldn't wait a second to implement a user-friendly user-interface change that tries to warn users whenever there are some unprintable characters within the password when the user first set up the password. Maybe even go further and FORCE the user after he/she sets the password, to unlock it at least one time to make sure that the unlocking works after the new wallet was generated etc (also this interface should warn about nonprintable characters, including BOM/carriage return/new lines etc) ...
One problem could be that the Mist password form actually never sees the carriage return/line feeds etc... it could be that the replacement already happens at a different layer, e.g. the operating system already does some manipulation and for instance the line feed will already be pasted as a different char into the password form (and it can't really be directly controlled/monitored/identified by Mist).

BTW, I tried to crack the ethereum_v3_broken_password.txt file from anormore (see above) and the password is " BrokenTest1!" (without quotes). i.e. a space at the beginning which is kinda strange (I think the user interface already shows this space though when you check the "Show password" checkbox... you could also copy-paste it again from the form and copy it back to the text editor and you will see a space).

$ JohnTheRipper/run/ethereum2john.py ethereum_v3_broken_wallet.txt > ethereum_v3_broken_wallet.hash

$ hashcat -m 15700 --outfile-format 4 ethereum_v3_broken_wallet.hash dict.txt
2042726f6b656e546573743121

Note: 2042726f6b656e546573743121 is the hex equivalent of " BrokenTest1!" (without quotes, but with a leading space)

Therefore the real discovery that wasn't mentioned yet, is that sometimes (maybe with a particular operating system or operating system version or mist version etc) spaces are inserted instead of the (hidden) control characters (including new lines).

philsmd on 29 Jan 2018

👍3

@anormore, @ontheronix, this is the article that states that high-n wallets cannot be cracked with hashcat due to memory limitations: https://stealthsploit.com/2018/01/04/ethereum-wallet-cracking-pt-2-gpu-vs-cpu/. If this is true I'll have to get a fleet of AWS machines to do the cracking, which would turn out expensive. Anyone experience hashcatting Mist / high-n wallets?

JamesDall on 29 Jan 2018

@philsmd Very interesting that you could use a space instead of the return character....

I just tried as well. You can indeed use a space instead of a return character and it gets added.

I guess I'll try adding a bunch of spaces to my password in Hashcat.

@JamesDall You'll probably want to use EthCracker, in my opinion it's better than Pythrecover. It's pretty good stuff, I did billions of combos with AWS just like you did (PS, Google and Microsoft offer free $300 bucks for new customers ;))

EthCracker recently added "Start at 50%" so you can divide up the workload nicely now.

anormore on 29 Jan 2018

Really annoyed developers havent responded to this yet. We're sitting here with an identified bug, looking for additional support -- and they're silent.

anormore on 30 Jan 2018

👍2

FOR THOSE INTERESTED IN GETTING STARTED WITH HASHCAT FOR CRACKING THEIR ETHEREUM WALLET PASSWORD WHILE WE WAIT ON THE DEVS TO APPEAR

Here's what I did to get Hashcat to run on an Amazon EC2 c4.8xlarge instance running Ubuntu 16.04. I don't claim that this is the best way, or even the correct way, to install Hashcat. But it seems to have worked for me.

1) Create an AWS account, log in, configure a c4.8xlarge instance with an Ubuntu 16.04 image, create/download the .pem file, create a security group to allow access via ssh, and spin up the box.

2) Give the .pem file the correct permissions and ssh into the instance (replacing mycert.pem and the instance url with your actual pem file and instance url).
$ chmod 400 mycert.pem
$ ssh -i mycert.pem [email protected]

3) Update apt and install OpenCL
$ sudo apt update
$ sudo apt upgrade
$ sudo apt install ocl-icd-libopencl1
$ sudo apt install opencl-headers
$ sudo apt install clinfo
$ sudo apt install ocl-icd-opencl-dev
$ wget "http://registrationcenter-download.intel.com/akdlm/irc_nas/12513/opencl_runtime_16.1.2_x64_rh_6.4.0.37.tgz"
$ sudo apt-get install -y rpm alien libnuma1
$ tar -xvf opencl_runtime_16.1.2_x64_rh_6.4.0.37.tgz
$ cd opencl_runtime_16.1.2_x64_rh_6.4.0.37/rpm/
$ fakeroot alien --to-deb opencl-1.2-base-6.4.0.37-1.x86_64.rpm
$ fakeroot alien --to-deb opencl-1.2-intel-cpu-6.4.0.37-1.x86_64.rpm
$ sudo dpkg -i opencl-1.2-base_6.4.0.37-2_amd64.deb
$ sudo dpkg -i opencl-1.2-intel-cpu_6.4.0.37-2_amd64.deb
$ sudo touch /etc/ld.so.conf.d/intelOpenCL.conf
$ sudo vim /etc/ld.so.conf.d/intelOpenCL.conf
paste the following into intelOpenCL.conf and save the file: _/opt/intel/opencl-1.2-6.4.0.37/lib64/clinfo_
$ sudo mkdir -p /etc/OpenCL/vendors
$ sudo ln /opt/intel/opencl-1.2-6.4.0.37/etc/intel64.icd /etc/OpenCL/vendors/intel64.icd
$ sudo ldconfig
$ clinfo
$ cd /home/ubuntu
$ wget "https://codeload.github.com/hpc12/tools/tar.gz/master"
$ tar xzvf master
$ cd tools-master
$ make
$ ./print-devices

4) Clone and build hashcat
$ cd /home/ubuntu
$ sudo apt install cmake build-essential
$ sudo apt install checkinstall git
$ git clone https://github.com/hashcat/hashcat.git
$ cd hashcat
$ git submodule update --init
$ make

5) Install screen so you can start a cracking session and return to it later.
$ sudo apt-get install openssh-server openssh-client screen
$ exit

6) Move the seed file to the remote instance (assuming the seed file is on your desktop). I used ethereum2john.py to create my seed from my backup wallet.
$ scp -i ~/Desktop/mycert.pem ~/Desktop/myseed.txt [email protected]:~/hashcat

Here are a couple of sources to help you get started actually using hashcat:
• https://hashcat.net/wiki/doku.php?id=mask_attack
• https://www.4armed.com/blog/perform-mask-attack-hashcat/

Don't forget to spin down your instances when not in use. Good Luck!

branmcf on 30 Jan 2018

@anormore please let's keep this thread constructive.

I know how frustrating this whole process might have been to you and the others. Our joint effort has already resulted in lots of progress around here, including this latest hint on control characters.

This week (and the following) I'll be mostly focused on releasing a Mist+Wallet 0.9.4 version with security and bugfixes, then I'll go back with full attention to this issue, trying to contribute more to the discussion.

In the meantime, I'll be reading and contributing with this issue as time allows.

evertonfraga on 31 Jan 2018

👍5

Just wanted to add another report that I'm affected by this issue. I have a secure (alphanumeric plus special characters) password which I used for two wallets which were created within minutes of each other. For one, the password works, for the other it does not. The password was copied / pasted in both cases.

It doesn't seem likely that I'll be able to use hashcat or similar to crack it due to the length - I've been lurking and reading this and other associated issues for the past few months and have tried most of the recommendations to no avail. I'm interested to see if there are any developments, glad it's being investigated. Let me know if there's anything I can try / do to help.

twigusa on 31 Jan 2018

@twigusa I am in the same case of you but I created only one wallet with a long password 64 characters alphanumeric.

sebd-davra on 31 Jan 2018

Same case. very long alphanumeric password copy/pasted in mist.

What could go wrong when we copy/paste a password into a mist password field ? Can the content be changed by something else ?

ceric35 on 31 Jan 2018

👍2

This is what I get everytime I try to send my Eth to another wallet
fff

Tguillaro on 1 Feb 2018

Can anyone help with this?

Tguillaro on 1 Feb 2018

@Tguillaro try to reinstall the application.

sebd-davra on 1 Feb 2018

How do I make sure my coins on on there if I delete the wallet and
reinstall it

On Thu, Feb 1, 2018 at 4:31 PM, sebd-davra notifications@github.com wrote:

@Tguillaro https://github.com/tguillaro try to reinstall the
application.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-362408328, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZLE16z1irixzxy-8rIL1sche8tM1ks5tQi0ngaJpZM4RU48I
.

Tguillaro on 1 Feb 2018

Hi Guys, I unlocked my Mist "Etherbase" account today after 700+ days of lockout. I installed Mist 0.3.9 back in February of 2016, then after a month or so, shape shifted some BTC into Ethereum to load it up. A few weeks after that I attempted to move a bit of ETH and was prompted for a password which I thought I had never been asked for during installation.

Over the last few months I carefully reviewed my notebooks to get a sense of what was happening and my mindset back in Feb of 2016. I work in IT and keep daily notebooks, with to do lists, contacts, meeting notes and all the many passwords for the systems / environments that I manage. I gathered a list of close to 200 passwords that were self-generated for both work and personal accounts. Alot of these passwords were simple like Bitcoin1000, 2000 , some with with a single special character or an uppercase etc. None of them were complex machine generated passwords and most not longer than 10 characters. With these lists I varied them up a bit and let haschat run at them over several months with no success.

This week I set aside some time to review my notes again and have closer look at the PC that initially held the wallet. Well I fired up file manager and searched for every file created or modified on the date of the UTC wallet file creation. I come across a simple text file labeled ethereum buried on my desktop. Well this file contained the Ethereum password I was searching for so long.... a 14 random character Upper, lowercase letters and one number. This was obviously a password that I had created using some online password tool since like I said, I have always created generally weak passwords myself... Man did I feel stupid but very lucky at the same time. This password would have been next to impossible to bruteforce with hashcat given the current capacities of sram on commericial video cards. Now I was 1000% convinced that I had not been asked or entered a password at the time, looking over my notes, I see that the day I created the wallet was extremely busy for me, so I will assume the prompting and creation of the password was done in "automatic mode" where I was multi-tasking and not fully concentrating on this critical step.

So, that's my dumb story that I will try to never repeat again. I hope and pray all of you will eventually unlock your accounts. I will be keeping a close eye on Scrypt cracking advancements and report them here. I suspect with 10's and possibly 100's of millions dollars locked away in ETH wallets, this will accelerate custom GPU board development. I envision someday a group of locked out ETH users creating an ICO or a go fund me to do just that, but until then, Good Luck to you All.

ethtester on 2 Feb 2018

👍3 ❤2 🎉1

@Tguillaro dont delete, just reinstall.

sebd-davra on 2 Feb 2018

Unistalled it and clicked on the wallet to install it and this is what I
get

On Thu, Feb 1, 2018 at 7:32 PM, sebd-davra notifications@github.com wrote:

@Tguillaro https://github.com/tguillaro dont delete, just reinstall.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-362447972, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZO9XH8hxU6hTJ0ooycuShh9jC1Aoks5tQleNgaJpZM4RU48I
.

Tguillaro on 2 Feb 2018

123

Tguillaro on 2 Feb 2018

@Tguillaro please create a new issue for this, let's keep this issue on-topic!

bvdbos on 2 Feb 2018

I am literally just following the steps you told me to take and telling you
the results

On Fri, Feb 2, 2018 at 12:39 AM, Bas van den Bosch <[email protected]

wrote:

@Tguillaro https://github.com/tguillaro please create a new issue for
this, let's keep this issue on-topic!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-362491927, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZFFV131ZuKx8inDdBl8z3a1lCzpTks5tQp-rgaJpZM4RU48I
.

Tguillaro on 2 Feb 2018

@Tguillaro We understand that you're having troubles accessing your account, but this is an un-releated issue. The Ethereum wallet for sure has these kinds of troubles for many users, but please start a new issue to get yourself fixed up. Cheers and good luck.

anormore on 2 Feb 2018

@ethtester Thank you for your story. I went back through all my stuff from that time frame, and I believe your story has jogged my memory! Still going to need Hashcat to crack, but I'm more confident now I remember it. But I think I've tried this particular password before, but it means I for SURE copy and pasted it. Thus, the whitespace bug may still be valid. Setting up for a few days of cracking.

anormore on 2 Feb 2018

👍1

@anormore In the last few weeks I also researched another option; Hypnosis. I have read that hypnosis for recall has worked for some.. Here are a few names..... Good Luck!

Morpheus Clinic - Toronto
http://greenvillehypnotist.com/
Veronica Marimour - Moscow ?
Kemila Zsange - Vancouver

ethtester on 2 Feb 2018

❤2

Believe me... I'm about to try. Will see what happens at the end of this run.

anormore on 2 Feb 2018

😄1

Forget that issue, I can access it through the old version... I need to
know how to get my Eth off this crappy wallet

On Fri, Feb 2, 2018 at 10:54 AM, anormore notifications@github.com wrote:

Believe me... I'm about to try. Will see what happens at the end of this
run.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-362609350, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZGXesp2TT25Tyaqi2QLDA10Cyfduks5tQyLwgaJpZM4RU48I
.

Tguillaro on 2 Feb 2018

Just a general announcement:

https://www.reddit.com/r/ethereum/ is a great place to look for assistance.

I'm running https://www.reddit.com/r/ethereumlostpasswords/ as well, not a lot of activity there though. (which is good?)

You can also chat on Gitter: https://gitter.im/ethereum/home

--

Let's get back to Password related problems here folks! I'm going to do some more testing this weekend regarding the white spaces. I did actually find my password file after a LONG time looking. It was in the wrong place... I think. Anyway, things are making sense here... So I do believe this is a white space issue.

I'm going to see in what other circumstances I can screw up a wallet. I've got a Mac here, so maybe there's some whacky character map issues. What happens if I use a french keyboard layout? Does the hash change?

Stay tuned folks, cheers,

anormore on 2 Feb 2018

👍1

@anormore thank you for your effort in recreating a password bug. Its encouraging as I search for the password issue preventing me from accessing my own pre-sale wallet.

It can be discouraging to loop through the cycle of researching a solution, attempt it and have 'wrong password' return. After a year of attempting to access my pre-sale wallet I feel quite lost in the issues.

My new approach is to catalogue all the mentioned issues, suggestions and resolutions in a spreadsheet. The goal is to have some visibility and confidence of all possible ways to trouble shoot the issue, before I begin to attempt more solutions.

Would this be valuable to everyone? (I'm barely technical so it seems valuable from my perspective) Would this be something anyone would like to have shared around?

@evertonfraga you've listed some links on the first post of this issue. Would you have any other data you've collected on these issues to share?

ghost on 8 Feb 2018

As we don't have a way to generate a pre-sale wallet at the moment... I think we're kind of screwed. I'm 99% sure of my password, I've tried everything. Nope. Nota.

And I know there is a repeatable 'bug' with password inputs. At this point, I think I'm just fucked. Developers haven't really done anything, other than sort of acknowledge the issue.

At least I'm only "out" $100 bucks, from 4 years ago. So I can't really complain. But I can still be mad that this isn't a bigger issue.

But then again, I have no idea what's going on at Ethereum HQ and what priorities are. Hopefully one day this gets figured out, but at this point, I have to hang up my hat with this, and get back to my regular stuff. This took a lot of effort to learn...

Good luck to the next guy.

anormore on 9 Feb 2018

👍1

I'm 100% sure of my password after brute forcing millions of permutations against my pre-sale wallet. Something unknown is preventing me from accessing with my password.

@anormore I can see you've dedicated a lot of effort to discover the issue. Take some rest but don't give up. We'll get there eventually, if we persist with the issue and keep it front of the dev team's mind

ghost on 9 Feb 2018

👍2

I tried affixing and suffixing my password with 1,2 or 3 spaces in Ethcracker because I copy/pasted my password, but also with no result. Probably because I also have special characters in it. So it seems we have 2 seperate bugs.

I also can't believe the devs are still releasing new versions while this bug is in it!

ontheronix on 9 Feb 2018

We haven't been able to reproduce the special characters bug... We can definitely reproduce the spaces bug.

I guess what is next is to reproduce the special characters bug to build the proper mask still...

anormore on 9 Feb 2018

When installing Ethereum Mist, I hit the 'skip' button on the initial password creation section of the install. Using the 'light' mode, the Mist Wallet set up quickly and seemed functional.

Accessing 'geth' via the console, I used the 'account update' command to verify that the password was blank (no password), but found that a 'real' password was expected and could not continue further.

I then did a complete reinstall of Mist (deleting all data folders), but this time I entered in a password when it was first requested. I found that I was able to use 'geth account update' to verify that, indeed, the password was accepted and allowed me to re-enter the same password.

Skipping the password during initial installation creates a situtation where you're not aware that an unknown password was created until you actually try to send funds.

satori-q3a on 9 Feb 2018

👍6

Well done @satori-q3a

sebd-davra on 9 Feb 2018

Hello,
I found this comment and have just experienced the same issue. I installed the latest version of the Ethereum Wallet and skipped putting in a password. When I deposited Ethereum to the new wallet which was installed a couple weeks ago, I found that it asked for a password the send ether out.. I never created one?

JWSV on 9 Feb 2018

So the question to the devs is:

What's the default password for geth and/or what's the default password that Mist uses when creating a new account? If it's "null", then there's no way that it can be entered thru a console.

satori-q3a on 9 Feb 2018

❤1 👍1

I'm seeing that this question has been asked multiple times in different threads but with no response from a dev??

JWSV on 9 Feb 2018

Why can't you use the geth update to update the password from a null value?

JWSV on 9 Feb 2018

Honestly, if this is a bug, then the ether wallet is a real shit show. I downloaded a qtum wallet the same day as this shit ether wallet, loaded it up and sent out qtum, no problems. The qtum wallet has a simple accessible option to change your password if you need to OR input one if you want.

JWSV on 10 Feb 2018

It seems to be a one time setup bug in which you absolutely cannot skip the initial password creation stage of the Mist installation. Otherwise, it will create a new account with it's own password that's unknown to you. You can transfer funds to it but you cannot send from it afterwards.

To be safe, you MUST manually verify that the new password is applied to the account from geth, via the 'account update' command, thru the console before any funds can be transferred to it.

satori-q3a on 10 Feb 2018

The problem is I have Several Thousand Dollars that just got destroyed because of this f'ng bug. This is not a game and ethereum project needs to pull their collective heads out of their asses. This is a serious god damn problem with their wallet and makes them look like a joke. A ton of people use crappy windows and it appears that's where the bug is. Glad to be a guinea pig and lose thousands.

JWSV on 10 Feb 2018

👍2 ❤1

Wow if this is true, that's pretty fucking ridiculous. Unreal how there had been practical zero word from the devs.

This is not a minor bug, this is massive.

shopifymatt on 10 Feb 2018

@JWSV Can you (reliably) reproduce the problem with a new installation/wallet? I.e. after you backed up all your important files (especially the UTC/json file) and create a fresh/new installation... are you able to perform the same steps and come up with a (new) account that can't be accessed ?

The problem so far was that a lot of people claim that they have "this exact" problem but (besides the special character replacement "problem" from above, which seems to have nothing to do with mist, because anormore proofed that the problem of copy-pasting also happens if he uses his browser instead of mist) were unable to reproduce it. The other problem is that a lot of users that claimed that they are 100% confident that they never inserted a password, much later found out that they used a password that they use also elsewhere with slight modifications (e.g. to fit it to the password policy of greater than 9 characters etc).

I'm not saying that this is for sure what also happened to you. I'm not claiming that you 100% forgot the password or forgot that you typed a password.... but currently we have no proof (best would be video recording, screenshots or at least step-by-step instructions on how to reproduce it etc) that such a bug exists in mist.
Until now there was no user able to confirm here that s/he just (at this very moment, because s/he wanted to reproduce the problem) created a new account and s/he is unable to unlock it and that s/he can provide the UTC/json file for us and the devs to analyse (because there is 0 eth in it).

It also would make sense to add some more information about your setup, e.g. which mist version you used beforehand (and which version you use now, if they differ) and the operating system version and (in case you typed a password) the keyboard layouts, (if applicable) if you copy-paste the password etc.

Maybe by repeating the installation steps and trying to figure out what buttons you clicked when launching mist the first time etc ... you are able to pinpoint the problem even more (or instead figure out that you saw this "New Account" screen beforehand and suddently remember that you typed an easy password etc).

philsmd on 10 Feb 2018

👍1

At first, I thought maybe I had created a password and just forgot, but
after troubleshooting what I remembered, I don't believe that to be the
case. I downloaded two wallets on the 17th of Jan and installed them - An
ethereum wallet and a qtum wallet. I did not create passwords for either
and I vividly remember skipping the create a password step for ethereum
wallet. I do not remember creating a password and then having to verify
it. I also put my passwords on special paper so I don't forget and that
never happened. I had created a password for the qtum wallet at a later
date after playing around with it, but again, no memory of creating one for
the ether wallet.

In any case, I will back up the ethereum wallet and try to see if I can
recreate the problem by following the steps I remember taking. I didn't do
anything special. I just went to the ethereum.org website downloaded the
latest for win 7 x 64, unziped it, started the installation and skipped
all the way to the end as it was downloading. Once it was done downloading
I just left it open off and on for the last couple of weeks until I sent
ether to it.

Another interesting thing is that the wallet has a main account (ether
base) and another account called account 1. The ether is stuck in account

I never created two accounts, so I don't know if that is something that
happens automatically when you send ether to the wallet?

Some information:
Ethereum wallet win64 0.9.3 - the only version that I had, there were no
updates of an existing wallet.
Windows 7 x64

On Sat, Feb 10, 2018 at 1:40 AM, philsmd notifications@github.com wrote:

@JWSV https://github.com/jwsv Can you (reliably) reproduce the problem
with a new installation/wallet? I.e. after you backed up all your important
files (especially the UTC/json file) and create a fresh/new installation...
are you able to perform the same steps and still come up with an account
that can't be accessed ?

The problem so far was that a lot of people claim that they have "this
exact" problem but (besides the special character replacement "problem"
from above, which seems to have nothing to do with mist, because anormore
proofed that the problem of copy-pasting also happens if he uses his
browser instead of mist) were unable to reproduce it. The other problem is
that a lot of users that claimed that they are 100% confident that they
never inserted a password much later found out that they used a password
that they use also elsewhere with slight modifications (e.g. to fit it to
the password policy of greater than 9 characters etc).

I'm not saying that this is for sure what also happened for you. I'm not
claiming that you 100% forgot the password or forgot that you typed a
password.... but currently we have no proof (best would be video recording,
screenshots or at least step-by-step instructions on how to reproduce it
etc) that such a bug exists in mist.
Untill now there was no users confirming here that s/he just (at this
very moment, because s/he wanted to reproduce the problem) created a new
account and s/he is unable to unlock it and that s/he can provide the
UTC/json file for us and the devs to analyse (because there is 0 eth in it).

It also would make sense to add some more information about your setup,
e.g. which mist version you used beforehand (and which version you use now,
if they differ) and the operating system version and (in case you typed a
password) the keyboard layouts, (if applicable) if you copy-paste the
password etc.

Maybe by repeating the installation steps and trying to figure out what
buttons you clicked when launching mist the first time etc ... you are able
to pinpoint the problem even more (or instead figure out that you saw this
"New Account" screen beforehand and suddently remember that you typed an
easy password etc).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-364636371, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AioZenPS8GDGJ3F456dfbYUes0RhFGAlks5tTVXxgaJpZM4RU48I
.

--
John Stibal
2200 Grizzly Ave
Idaho Falls, ID 83402
208-569-3466

JWSV on 10 Feb 2018

@JWSV do you remember where and how you copied the ethereum address to make the payment ? Do you remember whether there was only one account or more at the time you performed the payment to that address ? Are you sure that after you first launched the mist application after syncing (main windows) that there was already the etherbase account (or even already 2 accounts) ?
Did you use geth (go-ethereum) or any other ethereum-related software wallet before installing/launching mist ? Maybe there was already one UTC/json file present on your system by a different application

philsmd on 10 Feb 2018

I just copied the address that was in the ethereum wallet by clicking on
the copy address icon and pasted it into the send space on the sending
website. I Thought there was only one account and that then noticed two
after the ethereum had arrived - but I'm not 100 sure because I wasn't
looking at this. There were no other UTC files on the computer that I know
of when I downloaded the wallet. I checked the ethereum folder on the main
drive and it was timestamped the same day I downloaded the new ethereum
wallet. The time stamp for the UTC files shows that they were both created
and last updated the day after I had downloaded the wallet. I did not use
Geth before installing the wallet, but I had used it after to try to change
the password.
Again, I never added another account, because you need to create a password
do that AND I definitely didn't do that.

On Sat, Feb 10, 2018 at 11:31 AM, philsmd notifications@github.com wrote:

@JWSV https://github.com/jwsv do you remember where and how you copied
the ethereum address to make the payment ? Do you remember whether there
was only one account or more at the time you performed the payment to that
address ? Are you sure that after you first launched the mist application
after syncing (main windows) that there was already the etherbase account
(or even already 2 accounts) ?
Did you use geth (go-ethereum) or any other ethereum-related software
wallet before installing/launching mist ? Maybe there was already one
UTC/json file present on your system by a different application

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-364678734, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AioZemfnwYjQlwdo0TYaLpmJC9-8jCo7ks5tTeBtgaJpZM4RU48I
.

--
John Stibal
2200 Grizzly Ave
Idaho Falls, ID 83402
208-569-3466

JWSV on 10 Feb 2018

Like mostly all other people, I know I have my password 100% correct. I typed in my password extra slow and I was paying extra close attention while entering my password. I typed it extremely slow with one index finger. I know my password is correct.

This is how the bug happened for me.
Step 1) I downloaded Ethereum Wallet Zip Folder 0.9.3 .... Then sent transaction before full node is synced.
Step 2) After full node is synced, transaction doesn't show up because full node sync missed block-chain information
Step 3) KEEP wallet back-up. Delete Ethereum Zip and Data
Step 4) Re-Download Ethereum 0.9.3 .exe NOT zip; and use back-up wallet file and then fully sync with LIGHT client. now, transaction DOES appears in light wallet.
Step 5) Try to send with light wallet 0.9.3 ............ get error "wrong password"
Step 6) Try every possible password combination EVEN THOUGH i know i typed the very first password correctly and extremely slow with one index finger.
Step 7) end
edit: no special characters !@#$%^&*()_+<>?/ were used

ghost on 11 Feb 2018

👍1

I'm just trying to understand/analyze the problem...
@RntfgTroy do you remember if you used the skip option at the very beginning ? You wrote "I downloaded Ethereum Wallet Zip Folder 0.9.3 .... Then sent transaction" , but I miss the information about where and when you inserted the password. Did you use the initial onboarding new account screen or did you skip it and later create a new account?
Did you use the backup feature of mist or did you back the keys up manually (by copying the directory/files)?
Did you inspect the dates of the UTC files? Did they change after you set the password (several days later)?
Do you see one or more accounts (only etherbase?) ?
Do you use any particular keyboard layout ? Which operating system do you use?
Did you try to use geth to unlock the account ?

Do you think you are able to repeat all those steps and provide a keyfile that can't be unlocked?
I think in theory one could even use the testnet to sent some coins (without losing any real money) if you think that it only happens after some transactions were performed.
It would be great if someone could reproduce these steps and maybe even is able to attach a keyfile (for which the password is known, with 0 eth in it or it only uses testnet coins) and maybe even show some video recordings or screenshots to proof that this problem exists.

philsmd on 11 Feb 2018

👍2

-I did not skip setting up a password. I used the onboarding screen for Ethereum Wallet Zip Folder 0.9.3 to set a password.

I backed up the keys manually in Ethereum Wallet not Mist.
I never set a new password... I only imported back-up keys... so the dates have always been the same and never overwritten them.
i did back-up two accounts. the main account & the second account. Im using a default keyboard layout on Windows 10.
i cannot use geth because the geth file won't download and what command line do i download in addition to geth in order to use geth?
and everyone has distinctly different steps that they did ... but everyone still has the same "wrong password" issue ...... in other words if someone didn't follow my steps above then they still get "wrong password"... in fact I've read through the forums and everyone does something different but still get "wrong password"... so it really has nothing to do with how we arrived here because everyone just gets "wrong password" no matter what. ... and im sure enough people have the right password for this to be considered an error in ethereum . think about it if everyone says they wrote their password down or used a password generator or copy & paste their password . then it must be a fault in ethereum.
-especially the special character problem is a direct fault at the password screen and has nothing to do with how you arrived there.
-and now the password screen in general has a direct fault with characters and spaces and everything and has nothing to do with how you arrived there
thanks for the response @philsmd

edit: and right now I have a small processor so I have to use that computation power to try some solutions, I cannot use that time and power to re-download and install the wallets and blockchains. First, I have spend that time and power on some solutions and downloading different wallet versions and block chains and after I have tried a few solutions, only then will i reproduce the bug by re-downloading a 0.9.3 full node because its a lot on my processor.

And by the way, I'm just finding out that this bug has been in reproduction for years now. Including the person who comments after this post. Thanks again for the comment @philsmd

ghost on 11 Feb 2018

👍2

and as i said ... sooooo many people wrote down their password & know it 100% correct and the wallet says "wrong password" .. this cannot be our fault...

you math guys know the truth ... the increase in people who know their password 100% correct means an increase in the event that this a fault. I'm not yelling .. I'm just using simple math... we already know that the special characters and spaces are a problem on the password screen. we cannot continue to tell people that they messed up. when this is obviously a problem with the password screen.
if it was one or two people but, its soooooooooooo many people who have their passwords 100% .. you guys already know the math on that. I'm not yelling I'm just saying a fact.

ghost on 11 Feb 2018

😕1 👎1

and what about people that didn't create a password at all. and they can't send transactions. this is obviously flawed.
on github the ethereum build is obviously failing...
can we get an update?

ghost on 11 Feb 2018

I'm appalled Ethereum.org hasn't acknowledged this issue in a more formal way, and basically ignores this thread.

I'm no lawyer, but man, the in-ability to access your account due to a bug should be a critical issue. I've taken basic steps to show a re-produceable bug. The fact that the Devs haven't sat down to do this themselves is sheer laziness.

IT'S LAZY

And now it's rude to ignore this issue completely.

What happens when this thread hits Twitter or goes big?

"Warning, do not buy Ethereum because there is a 5% chance you'll never unlock your wallet because of unknown bugs, which were reported to devs, but they didn't care".

There are more and more people coming here daily. I get messages on Reddit for from people asking for help. This is nuts.

I'm calling on Ethereum.org to step it up and address this community.

anormore on 11 Feb 2018

👍5 🎉1 👎1

However this fits into solving the problem-
Mac Os ether mist wallet (whatever version was in beg of Aug 2017- not presale. My password and my original wallet work fine. I created a second account within the wallet- I am sure I was never prompted to provide a password during this process as I write everything down. However, if I did create one, it has special characters and I know it. I sent ether to this wallet. when I tried to send ether out of this wallet, I am asked to provide a password- then the password doesnt work. Now I can stare at the account that has my ether and I have no access to it. I have tried downloading and using other wallets with my jstore file, and using myether- I have access to everything but that one account. ethereum was great for paving the way...but my faith will have to lean towards other platforms in the long run. If you think I made a mistake or am wrong, i dont care. I learned my lesson- but I do hope a remedy is found for all those who have suffered losses from this bug.

lucas-iao on 12 Feb 2018

Ok,
So, I resintalled the ethereum wallet today using the same steps that I did
before. However...This time, NO accounts showed up in the wallet. Where
and how ethereum wallet is creating these accounts out of thin air is
freakn' amazing. If the wallet is picking up old UTC files or
incorporating unknown files into a "new installation", that is a serious
problem for new users. The system I originally installed the wallet on
didn't have any previous ether installations to my knowledge and even if it
did, the wallet shouldn't be importing old files into a new
installation without your permission so you know whats going on! I am
going to restore windows back to its state before the first installation to
see what happens.

On Mon, Feb 12, 2018 at 7:37 AM, lucas-iao notifications@github.com wrote:

However this fits into solving the problem-
Mac Os ether mist wallet (whatever version was in beg of Aug 2017- not
presale. My password and my original wallet work fine. I created a second
account within the wallet- I am sure I was never prompted to provide a
password during this process as I write everything down. However, if I did
create one, it has special characters and I know it. I sent ether to this
wallet. when I tried to send ether out of this wallet, I am asked to
provide a password- then the password doesnt work. Now I can stare at the
account that has my ether and I have no access to it. I have tried
downloading and using other wallets with my jstore file, and using myether-
I have access to everything but that one account. ethereum was great for
paving the way...but my faith will have to lean towards other platforms in
the long run. If you think I made a mistake or am wrong, i dont care. I
learned my lesson- but I do hope a remedy is found for all those who have
suffered losses from this bug.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-364940901, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AioZemEWBqcI05WXKQDn7DqsLsP8mEEvks5tUEy4gaJpZM4RU48I
.

--
John Stibal
2200 Grizzly Ave
Idaho Falls, ID 83402
208-569-3466

JWSV on 12 Feb 2018

Hey guys,
Unfortunately I have the exact same problem. I'm sure I did not set up any password, as I skipped it and it created my main account. I've been trying to brute force, however I'm certain there was no password. I'm really pissed. I have a great memory and always write everything down...when I first tried to send some coins to an exchange I was really suprised it asked me for password cause I never set it :(

lexie1 on 13 Feb 2018

@evertonfraga Are there reports about passwords with underscores ( _ ) in it?
Can you provide a list with troublesome characters derived from the input of the Google form?

ontheronix on 14 Feb 2018

i have an update: i was thinking about my password today.. and i thought i remembered it.
So i tried it and it didn't say wrong password, it said no peers connected.
but usually if peers are not connected it would just say wrong password.
so to make a long story short it still says wrong password.

but I know i wouldn't make my password anything else.
and i specifically remember typing the password extra slow with one finger and showing password and everything and using my extra familiar password.
and if i had to add a character then it would only be a "9"

but to make a longer story shorter. i know my password however i tried all different passwords and password mistakes just for kicks. but i specifically remember installing my password.
because all wallets says do not lose your password

this is exactly what i was trying to avoid, not having anyone to go to for a password
thats why i looked at the password and i own crypto wallets im responsible . but this time it wasn't me.

and earlier versions didn't work either because the keys have a different format now for 0.9.3
to make a longer story shorter can you guys please make an update, where the passphrases hashes are corrected.
my password cannot possibly be anything else . i tried my password, i tried password mistakes , caps lock. like im trying all this stuff for no reason my brain is stuck on my real password . I don't understand.
why guys why 😞
edit: i didn't put any fancy stuff that i would forget. like specifically put it as my other password. it has the exact same length ... i remember the dots length and i looked at it specifically
i just guys why 🤕

ghost on 15 Feb 2018

also if my password length is less than the required.. but i know i my password 100% true can the next update remove the requirements. guys 🤕
i still don't understand why people copy&paste their password and it doesn't work.
but on the next update can the password requirements be removed because it could be that my password length is lesser than required length. guys
why would it allow a password to be created that doesn't meet the requirements
why would it allow a password to be created that doesn't meet the requirements
why would it allow a password to be created that is zero characters or lesser than required
whyyyyyyyyyy i just don't get it 😞

ghost on 15 Feb 2018

Ethereum is bugged, and you're out of luck. No response from developers despite hundreds of cases from users.

Kiss your ETH goodbye.

anormore on 15 Feb 2018

😕2 👎1

yep it's an ether trap.

sebd-davra on 15 Feb 2018

@anormore and others that have a pre-sale generated wallet/json file.
Since @evertonfraga and other devs here only promised to show the code of the wallet generation of the pre-sale website but never delivered, I took some spare time and tried to investigate...
With archive.org or archive.is the old versions of the ethereum.org website are still available and I also discovered the wallet generation code (genwallet ()).
It's actually similar to the pyethsaletool tool (but with the extra bkp field) which is available here: https://github.com/ethereum/pyethsaletool... but implemented in javascript.

Here are some interesting links:
https://www.reddit.com/r/ethereum/comments/2bilqg/note_there_is_a_paranoid_highsecurity_way_to/cj5yda2/
https://web.archive.org/web/20140824160929/https://www.ethereum.org/
https://web.archive.org/web/20140824160929js_/https://www.ethereum.org/scripts/app.min.js

It's interesting that the charset for the seed consists of "only" these characters: "abcdefghijklmnopqrstuvwxyz234567" (see the n.entropy+="abcdefghijklmnopqrstuvwxyz234567"[t%32] from the app.min.js file above).... but at the other hand also the pyethsaletool seems to have used a restricted charset for the seed (only using hex chars, "0123456789abcdef") after this commit
https://github.com/ethereum/pyethsaletool/commit/6c2ff9aa8693b25d406d4e6908a2d00913fee51e
(I have also explained some possible attacks that could be performed here: https://hashcat.net/forum/thread-6405-post-39256.html#pid39256 if you for instance know how long the raw seed is - padding attack - or how the charset was restricted)

To make it clear, all those possible ways to "attack" the encseed of a pre-sale wallet do not really make it much more faster to crack (because the speed gain should be negligible compared to the slow/heavy pbkdf2 part), but they for instance allow to not disclose/provide the whole encseed to strangers (e.g. password recovery services), but still let them try a lot of password candidates to recover the seed/private key.

this could also be interesting https://forum.ethereum.org/discussion/1159/why-do-the-sale-webpage-and-python-command-line-tool-produce-very-differently-sized-encseeds , Vitalik explains why the encseeds are much longer for wallets generated by the website.

philsmd on 15 Feb 2018

👍2

Hi all,

I managed to find the code that generated the presale wallets, with the help of @cdetrio. You can run that website and see if the account created from there can be unlocked by Geth.

wallet generation code:
https://github.com/ethereum/www/blob/514c99663ebd5b276652ee1be377e560a092fbbf/src/scripts/libs/ethersale/xethtool.js#L67-L81

where genwallet is called from the interface
https://github.com/ethereum/www/blob/514c99663ebd5b276652ee1be377e560a092fbbf/src/scripts/ethapp.js#L167

commit history from that time https://github.com/ethereum/www/commits/master-sale?after=057b87516d3373cda55143e7f24bf91e77fb5259+34

evertonfraga on 15 Feb 2018

@evertonfraga this is the kind of stuff that makes me think this is on you.

My purchase date is: 8/9/14

The pythesaletool was changed on: 09/11/14

The Change:
https://github.com/ethereum/pyethsaletool/commit/6c2ff9aa8693b25d406d4e6908a2d00913fee51e

random_key()
random_key().decode('hex')

@philsmd -- does this make sense? Would this have anything to do with my lockout or any one elses specifically? It appears they changed the way passwords are generated.

I'm wondering if all the tools including Hashcat are not including "my non decode('hex') wallet"?

@evertonfraga If I generated a wallet before this update, and one after this update, using the same password with some sort of special character -- the output hash would be different, yes?

anormore on 15 Feb 2018

@anormore pyethsaletool was not directly used within the webpage.

I think the change of using hexadecimal instead of unhexing it has to do with the fact that an user could provide the seed with the command line argument

--seed seed

to pyethsaletool and therefore it can't always be hex-decoded (if hex chars were not used in the first place). I think this was a "bug" (again only pyethsaletool not the webpage) in previous versions of pyethsaletool that it always tried to unhex the seed provided by --seed... now the change introduced a slight weakness/vulnerability because we have a known-charset that we can detect with password recovery tools and make educated guesses if the decryption worked even without the sha3 step or even without having the whole encseed.

Again, I do not think that the page was modified too with these hex-changes (now you also have the commit log so maybe you can find it out yourself, but I'm pretty sure the javascript version wasn't change the same way).

The hex-change does not change much in the algorithm. If anything the seed and encseed would be much longer (twice as long compared to non-hex version seed). It wouldn't make it uncrackable and you wouldn't need a different algorithm to crack it (it is just longer, if anything).

I wouldn't say that "hash would be different", it's always differerent for instance because we have a random initialization vector (IV) for the AES key etc.... This is also no problem for the password crackers and it wouldn't make it uncrackable.

philsmd on 15 Feb 2018

So, it's not possible for me to reproduce the bugs from the staging.ethereum.com website. Who knows how they were grabbing input and transforming it.

Still waiting here for a dev response. @evertonfraga

anormore on 20 Feb 2018

@anormore

this is the kind of stuff that makes me think this is on you.

You make assumptions out of imprecision, and that does not help us progress.

This issue was created to collect user feedback regarding different types of wrong password claims and try to figure out a pattern that could lead to more specific testing scenarios. As a reminder, we've already spent lots of hours and haven't reproduced a single wrong password case.

Although I'm designing new testing scenarios with the collected data as input, I'm afraid your problem does not even fit in this issue — it was a presale wallet which password didn't work with Ethereum Wallet. Also MyEtherWallet, Geth, Parity and so on.

I've identified several possible causes to "Wrong password" issue, and clearly, your problem is not with this software. I tried my best to respond to off-topic questions you made, but let's keep an EthereumWallet-wise conversation.

evertonfraga on 21 Feb 2018

https://github.com/ethereum/mist/issues/3513#issuecomment-357752330

evertonfraga on 21 Feb 2018

Man, my password is a super simple password. There’s a LOT of problems with ethereum.

Since you’re going to take weeks to respond, and not really provide any solutions, I’ll just leave. But the fact remains there ARE problems and I have in fact given steps to reproduce the bug. Copy and paste a line break and it will absolutely change the wallets hash. It has been created with extra data instead of stripping it to out.

I purchased as a presale wallet, I cannot actually contribute as I cannot actually generate a new wallet.

I sense the growing anger and frustrations here.

AndyNormore on 21 Feb 2018

everyone, i already commented so i won't jam the thread anymore. I just want to say that I know clicked "view password" and i specifically know that is the same as another password. I typed it extremely slowly with one finger and viewed the password. Even though I have tried every possible combination.... it cannot be anything else. so many people use password managers and copy + paste and their password doesn't work either.
anyway this is not an argument.
I just went ahead and burned my ether at the stake. burning my ether at the stake meaning deleting the keys. It was over half an ethereum and i am the upmost glad the I had not put 2, 3 or 4+ ether in here.

anyway this isn't a threat or argument. i just burned my ethereum at the stake. I'm over it.
Good Luck All
I won't be back

ghost on 21 Feb 2018

Still can not transfer my Eth out of this wallet... I know my password and
every variation I have ever used, it does not work!!!
I just want to transfer my coins out of this crappy wallet for fuck sakes

On Wed, Feb 21, 2018 at 5:41 PM, RntfgTroy notifications@github.com wrote:

everyone, i already commented so i won't jam the thread anymore. I just
want to say that I know clicked "view password" and i specifically know
that is the same as another password. I typed it extremely slowly with one
finger and viewed the password. Even though I have tried every possible
combination.... it cannot be anything else. so many people use password
managers and copy + paste and their password doesn't work either.
anyway this is not an argument.
I just went ahead and burned my ether at the stake. burning my ether at
the stake meaning deleting the keys. It was over half an ethereum and i am
the upmost glad the I had not put 2, 3 or 4+ ether in here.

anyway this isn't a threat or argument. i just burned my ethereum at the
stake. I'm over it.
Good Luck All
I won't be back

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-367502059, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZNQo_Kz8VdKcakKO7i93tEDB6aPbks5tXJuEgaJpZM4RU48I
.

Tguillaro on 22 Feb 2018

@Tguillaro we want all the same, but nobody is able to reproduce the problem, but the issue is still real.

sebd-davra on 22 Feb 2018

Lmao, They're not able to reproduce the problem yet everyone is having this
issue... Come on Eth, get your shit together!

On Thu, Feb 22, 2018 at 4:52 AM, sebd-davra notifications@github.com
wrote:

@Tguillaro https://github.com/tguillaro we want all the same, but
nobody is able to reproduce the problem, but the issue is still real.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-367626414, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZBRMcmGsS9pU6LKJGBw5iFhslvenks5tXTjAgaJpZM4RU48I
.

Tguillaro on 22 Feb 2018

Attention newcomers! It is not entirely true that the problem has not been reproduced: Anarmore has reproduced the problem of copy/pasting the password. See some posts above.

The problem of special characters has not been reproduced yet but it is very likely that it happens since the charset has no special characters in it (see philsmd's post).

ontheronix on 22 Feb 2018

So what does that mean for us.. Can you fix the issue or are we all SOL on
the money we have in this wallet

On Thu, Feb 22, 2018 at 10:29 AM, ontheronix notifications@github.com
wrote:

Attention newcomers! It is not entirely true that the problem has not been
reproduced: Anarmore has reproduced the problem of copy/pasting the
password. See some posts above.

The problem of special characters has not been reproduced yet but it is
very likely that it happens since the charset has no special characters in
it (see philsmd's post).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-367717245, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZD48joBPs4rzNsqJa1dqMvuH4sT7ks5tXYf2gaJpZM4RU48I
.

Tguillaro on 22 Feb 2018

It has been over a year since I was locked out of my wallet waiting to hear a solution. It’s hard to walk away from 16 ethers. Perhaps Ethereum is just another internet scam. “Bitconnect” I agree with AndyNormore “anger and frustrations” I still remember seeing my balance every day after I transfer my bitcoin into The Mist ethereum wallet and one day I turned my computer back on and All was gone....the rest is history.. Ethereum built a business out of stilling money from hard working people.

73theconnector on 24 Feb 2018

Right, this is bullshit, I made a transfer to this wallet when it was 20
bucks a coin... That's a shit ton of money now >_<

On Sat, Feb 24, 2018 at 8:40 AM, 73theconnector notifications@github.com
wrote:

It has been over a year since I was locked out of my wallet waiting to
hear a solution. It’s hard to walk away from 16 ethers. Perhaps Ethereum is
just another internet scam. “Bitconnect” I agree with AndyNormore “anger
and frustrations” I still remember seeing my balance every day after I
transfer my bitcoin into The Mist ethereum wallet and one day I turned my
computer back on and All was gone....the rest is history.. Ethereum built a
business out of stilling money from hard working people.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-368229190, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZF5Ik_vSxLQnr70lDZDCPovlfBIFks5tYBFmgaJpZM4RU48I
.

Tguillaro on 24 Feb 2018

"Sorry, nothing to see here, there are no bugs and we do not plan to fix any of these bugs, because we can't reproduce them, because they don't exist" ~_Ethereum probably_

@evertonfraga This is how you sound and the community is growing frustrated. How long do you think this problem can continue before there are _major_ disruptions in your organization from this? The history of this ticket is insane with a complete lack of support from the Ethereum organization.

anormore on 25 Feb 2018

👎1

@evertonfraga

You make assumptions out of imprecision, and that does not help us progress.

What have you done on your end to progress? I've submitted to you a completely reproducible method to break wallets, which you've ignored.

anormore on 25 Feb 2018

@evertonfraga

https://github.com/ethereum/mist/issues/3513#issuecomment-361083428

Go ahead and remind me that I've not submitted to you a way to create a reproducible bug.

I submit to the community that this bug is ABSOLUTELY repeatable, and because this is a real bug, it isn't impossible to accept that there are additional bugs. Additional bugs like character sets or other things inserting crappy HTML into the input field, or some one's lazy javascript to fetch the input of the textbox that also screwed up input.

For me, I ordered on staging.ethereum.org and cannot at all inspect the code to debug further. So for me, this journey is over and is up to Ethereum to investigate and fix. Because of the reproduce able bug that still exists in the most recent version of Ethereum, that this was present at the time of the presale. I would suggest that other characters could also make their way in.

OR -- Ethereum.org has deliberately sabotaged wallets some how to keep a certain percentage of their value locked in. I hope it's not true, but organizations do this. I'll never know, because the presale code isn't available to double check. Tinfoil hat time for sure, but I'm not the only one thinking it.

@evertonfraga You should ask your marketing team to inspect this thread, and this should be escalated right up to VITALIK BUTERIN @vbuterin and @obscuren

It's clear that @evertonfraga has lost interest in maintaining this thread.

I'm calling on the community of lost Ethereum users to tag @vbuterin for an official response to this issue.

anormore on 25 Feb 2018

👎1 👍1

@anormore I fully agree. Maybe it must be taken to the press before there is finally going to change something.

ontheronix on 25 Feb 2018

Okay, let's take a deep breath. I understand perfectly well that you're exceptionally stressed, angry, desperate, etc. if you're locked out of your funds. I don't blame you; I would feel similarly.

Please know that we devs still put in some time each week on this issue. I read each new thread post in my email. We test every theory that people come up with (including yours @anormore; I was able to access a wallet by subbing a space for the linebreak in the password. Happy to test more character combos, etc.). Users report all sorts of scenarios that lead up to them being locked out of their accounts. Not once have we been able to find a reproducible bug.

The fortunate resolution for many of these reports are that users discovered their password was something they'd forgotten or mistakenly entered. @anormore, in a calmer state, you've said "I'm fairly certain I have simply forgotten my password and am running Hashcat."

I'm not saying its impossible that a bug exists. Some bugs are especially difficult to reproduce, because they require many stars to align, so to speak. Because we've been unable to reproduce any of the reports so far ourselves, we have to rely heavily on users reporting the detailed specifics when they believe they've run into such a bug.

Again, I get your frustration, but please knock off the abusive language towards members of the dev team. Despite your accusations, we do give a damn about your situation, even if you just forgot your password. In the meantime, we're also busy simplifying things for new users, like removing the ability to create accounts in onboarding. In an upcoming release, we plan to introduce mnemonics and other friendlier user experiences.

I sincerely hope you recover access to your wallets. If you want to help us (and yourself) please limit all future posts in this thread to technical discussions.

marcgarreau on 28 Feb 2018

👍4

While I appreciate your reply, you make it sound as though because I have previously stated I may have simply forgotten my password, that I have -- and you're washing your hands of that. The truth is that I have tried my password that I'm extremely certain that it is, but your system says it is wrong. Because of this, my certainty is shaken. That's all. Do not try to claim that I am 100% wrong. We're 50/50 on this. It could be my fault, yes -- but it may also be your fault.

Your entire attitude towards this is that it CANNOT be your fault.

I was able to access a wallet by subbing a space for the linebreak in the password. Happy to test more character combos, etc

Do you not see how this is a big problem, and that YOU should be _happily_ testing more scenarios?

It has been a number of weeks since you wrote back here, which this thread see's as rude. Not that I in anyway speak for the group here, but it's pretty lazy that you can't reply back. Even this reply adds nothing of value to the topic, despite acknowledging that you can 'substitute a space for a line break'.

Do you not see that as a BIG PROBLEM?

anormore on 28 Feb 2018

👎1

Let's try to focus on the facts that we found out so far:

whenever a user copy-pastes a multi-line sequence of characters (string) to a single line input field, the new lines will be converted to spaces. I did some tests and this is what each and every browser I tested does too (and anormore even proofed that his browser did the same because his myetherwallet test with " BrokenTest1!" account was unlocked even though he copy-pasted a newline and his browser (pointing to the input field of the myetherwallet page) also replaced the newlines with spaces). My guess is, that this is because single line input fields are not multi-line textarea fields where newlines are allowed. I don't think that this newline replace problem is somehow preventable/detectable except if Mist monitors the clipboard before the pastes etc (which could be evil/dangerous by itself).
It is actually pretty easy to generate accounts/json files with the (pre-)sale webpage and @evertonfraga and me already mentioned how to do so: https://github.com/ethereum/mist/issues/3513#issuecomment-366013278 and https://github.com/ethereum/mist/issues/3513#issuecomment-366007905 . With the local copy of the webpage which does all the account generation with just a few lines of javascript, you could easily generate a lot of json files, try to crack these with hashcat and try to find bugs etc. I also explained how I did some tests here: https://pastebin.com/raw/aXrn4t8d and https://hashcat.net/forum/thread-6405-post-39256.html#pid39256 . I actually believe this whole discussion about pre-sale is mostly off-topic because it has very, very little to do with this repository, i.e. the mist software. For pre-sale the account generation was done within your browser. Mist is an independent desktop application, even though it uses electronjs which also is browser-based. The only "problem" that I faced on how to launch the account-generation routine was that the time period was over so I had to manually run a piece of javascript within the build webpage to force the page to load the "start ether purchase" action: document.getElementById('start-ether-purchase').click()

philsmd on 28 Feb 2018

👍2

@marcgarreau What is the definition of a bug? You devs always keep saying there are no bugs, but how is converting line characters to spaces normal behaviour??
@philsmd Imo we have also the issue of the limited charset. It was possible to use special characters while it was not in the charset:

It's interesting that the charset for the seed consists of "only" these characters: "abcdefghijklmnopqrstuvwxyz234567" (see the n.entropy+="abcdefghijklmnopqrstuvwxyz234567"[t%32] from the app.min.js file above).... but at the other hand also the pyethsaletool seems to have used a restricted charset for the seed (only using hex chars, "0123456789abcdef") after this commit

ontheronix on 28 Feb 2018

@ontheronix I think this is a misunderstanding and I'm very sorry if this misunderstanding comes from my wordings of my posts, but I think I made it pretty clear that the limited charset only affects the seed itself, not the password.
I think there is no restiction on the characters that can and could be used to make up a password.
The seed on the other hand, is this random long string which determined the private key (and public key and ether address etc) and this seed was somehow randomly generated, but the way it was/is encrypted for pre-sale accounts is that the seed either is all in hex (for pyethsaletool) or is using the limited character set of abcdefghijklmnopqrstuvwxyz234567 (for the ethereum.org pre-sale website).
Again, we should not confuse the seed with the password itself. The password seems to allow any characters (maybe except new lines because they are difficult to enter in a single line text input field), while the randomly generated seed is somehow not using the whole 0x00-0xff byte range and therefore it is somehow detectable if the encseed (encrypted seed) was successfully decrypted if the decrypted encseed (aka the seed) does not use a single character outside the allowed range. This is just a possible attack scenario and a possibility on how you can avoid sharing the whole encseed without the risk of handling over the whole "data" to e.g. a password recovery service (which could just generate the private key from the seed whenever they found the correct password to decrypt the entire set of bytes that are needed for the encseed, if they had the whole encseed).

philsmd on 28 Feb 2018

I would suggest that we try again focusing on the Ethereum Wallet or Mist problems here and I know that a lot of my posts were also about pre-sale, therefore I took some time and tried to investigate if I can reproduce the account-I-never-created problem... and indeed after just a couple of seconds/minutes after installing the latest Ethereum Wallet release version 0.9.3 from (https://github.com/ethereum/mist/releases , this version: Ethereum-Wallet-installer-0-9-3.exe) I was able to suddently find a UTC file in the keystore folder for which I never created an account.
(it is sad to find out that something like this is very easy to discover and until now not a single dev or affected user was able to test/discover this. If I were an affected user who can't access a lot of ether I would click on each and every possible button and try each and every mist/ether wallet version. If I were a dev I would try to find each and every possible way UTC files can be created and implement a lot of unit/integration//functional etc tests and also would try all possibilities on how to crash the software or find bugs)

The steps I used after installing Ethereum-Wallet-installer-0-9-3.exe :

launch it
choose main net
skip password (in a later test I discovered that the "skip password" screen was indeed not shown a single time, but even if I deleted all files from the %APPDATA% folders, I could click on "Launch application", maybe because of a network/connection problem... but this explains why some users don't even remember seeing a skip option)
click on the Menu: Develop -> Network -> Solo network
after that my %APPDATA%\Ethereum\keystore folder suddently had a new UTC file (without extension, no json extension)
after switching back to the main network I saw something like this (attention: I made the screenshot after the second account creation, because after the first one I didn't have a clue that this has to do with the "Solo network" option at all)

ethereum_network_switched

So this means that:

no password was entered
the user has no clue that this account was created automatically with empty password (zero length password) and that this account was meant for the "dev" Solo network
the user might expect that this is a normal account and transfer some ether to this (it might also be a "normal" account, but it doesn't respect the password policy and there was no account creation dialog in use at all)

I also discovered that also some other menu options might create new accounts in the background but I didn't investigate this yet. For instance look at this code: https://github.com/ethereum/mist/blob/ee1ddfaa6ccf5ff15170a2f7836ef057023ac3c1/tests/wallet/basic.test.js#L87 launched from this test https://github.com/ethereum/mist/blob/ee1ddfaa6ccf5ff15170a2f7836ef057023ac3c1/tests/wallet/basic.test.js#L47 . What is weird to me is that even if such a test is run with password "1234" there should be code that deletes this test account (I didn't find the corresponding code maybe because it doesn't exist, which is very dangerous). A user might run the "tests" because he is paranoid and wants to make sure that everything is working correctly and after that s/he transfers some ether to the default account (it is not obvious that this shouldn't be used normally and why and how this account was created) and does not know that the password is "1234" to unlock this. (additionally, I do not understand how the password could be "1234", this doesn't even follow the minimum password length policy)

Of course, for both cases the passwords are very easy, either the empty string or "1234", but still these confusing new accounts shouldn't be created automatically at all or it should be somehow prevented that the user uses these test accounts to transfer a lot of money.

Attached are 2 UTC files that were automatically created by the "Solo network" option without seeing/launching the account creation dialog at all. In my opinion we can't assume that nobody ever clicked on the network change menu, especially since we all know that there could be a lot of syncing problems.
ethereum_keystore1.zip
ethereum_keystore2.zip

philsmd on 1 Mar 2018

👍5

@philsmd,

Exactly my case! Exactly! Thx for investigation!

alllev on 1 Mar 2018

Also the use-case I have with >100 eth in a wallet of an acquintance... He skipped passwords on 0.8.x on an apple.

bvdbos on 1 Mar 2018

I also did not enter any password, as I skipped it and it created my account...hopefully one day it will be resolved.

lexie1 on 1 Mar 2018

Exactly my case! Exactly! Thank you for the investigation!
So, this means that I could transfer my ether to another wallet by simply
typing “1234”

On Thursday, March 1, 2018, alllev notifications@github.com wrote:

@philsmd https://github.com/philsmd,

Exactly my case! Exactly! Thx for investigation!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-369592861, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiqMg6HrhDFlQavSnHHkDAcgxYLdhucjks5tZ_kdgaJpZM4RU48I
.

73theconnector on 1 Mar 2018

I never entered a password either

On Thu, Mar 1, 2018 at 9:42 AM, 73theconnector notifications@github.com
wrote:

Exactly my case! Exactly! Thank you for the investigation!
So, this means that I could transfer my ether to another wallet by simply
typing “1234”

On Thursday, March 1, 2018, alllev notifications@github.com wrote:

@philsmd https://github.com/philsmd,

Exactly my case! Exactly! Thx for investigation!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-369592861,
or mute
the thread
AiqMg6HrhDFlQavSnHHkDAcgxYLdhucjks5tZ_kdgaJpZM4RU48I>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-369612988, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiTVZN3l80iv14Sb8-AvbKLVmTW3AZkaks5taAjxgaJpZM4RU48I
.

Tguillaro on 1 Mar 2018

@philsmd , I sent my Bitcon to the Ethereum Mist Wallet back on March 05, 2016 using what I believe is Wallet 0.5.2 (Beta 10). Here are the additions to this version.

"This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout".
I don't have a recollection from Ethereum Mist Wallet requesting to create a password @ the moment of creating the account I used to send my Bitcon to the Ethereum Mist Wallet.

73theconnector on 3 Mar 2018

Sorry @73theconnector , but I really do not know what happened in your very specific case and I also don't think this is the correct place to start wild discussions about what could have happened to each and every affected user. I think we should focus on delivering facts and helping the devs to identify and fix the problems. For other non-technical discussions you might better use different platforms like: https://www.reddit.com/r/ethereumlostpasswords/ (which @anormore posted above) etc. Don't get me wrong, I also think discussions about these problems are needed, but github is a platform where you normally report detailed bug descriptions and technical facts/solutions.
I also do not like that so many people claim that this is "exactly my case!" now ... but before I posted the problem with the new "random" account creation when using the "Solo network" option nobody said that they clicked on "Solo network". Unfortunately, this makes the whole set of affected users even more incredible (besides the already large number of cases where users claimed they for sure used a specific password and later on it turned out that they used a different one, because now they know after e.g. a password recovery service cracked it).
Therefore, in my opinion it doesn't makes much sense to just answer to new findings with "this happened also to me". Use the emojis etc if you only want to express your emotions but at the same time you have no additional information to share or further contributions to make.

On the other hand, I would expect answers from the devs (@evertonfraga, @marcgarreau, @alexvandesande, @frozeman etc) at least after some interesting new discoveries were made. Maybe they are busy reproducing/confirming/fixing the problems already, but a message about the progress and acknowledgement of the bugs would be nice. Otherwise, my motivation about helping with this issue will become very tiny. After all I'm neither an ethereum dev, nor an affected user.

Today I started the latest Ethereum Wallet 0.9.3 again and found at least 2 further problems/bugs that I want to report below:

encoding problem with "special characters" within the password
geth copy-paste / account creation / unlock problem with special characters within password

To reproduce the first problem you just need a text-editor (or hex editor, I used the HxD hex editor just to make sure about the encoding) and Mist/Ethereum Wallet.

create a password file "pass.txt" with the password "1234Ó678" (without quotes, the hex characters are 0x31 0x32 0x33 0x34 0xd3 0x36 0x37 0x38 , the number 5 was intentionally omitted to make it clear that the special character is the character number 5):
copy the password to your clipboard
open mist and paste the password into the new account creation dialog:
copy the password again in the password confirmation field and click OK
the account is successfully created and will be displayed in Mist/Ethereum Wallet:

The example keystore UTC file can be found here:

UTC--2018-03-03T19-21-38.282559300Z--08899c7e02e069f9abdedea62c8465eeafad6779.txt
(I will upload the UTC files with .txt extensions otherwise they are not accepted by github)

The problem now is that this account can't be unlocked with the ANSI byte sequence 0x31 0x32 0x33 0x34 0xd3 0x36 0x37 0x38, but you need to use the UTF-8 bytes 0x31 0x32 0x33 0x34 0xc3 0x93 0x36 0x37 0x38 (note this now uses the hexadecimal character 0xc393 instead of 0xd3).

Also the password crackers will succeed with the password if you use the UTF-8 encoded password, but fail with the original one (because mist/ethereum wallet generated the keystore file with different encoding):

$ethereum$s*262144*8*1*5a7e01e3a3b14fd786e191524dc22f0d04048e66fecb7d7f2c8b6065c7159c38*97ce71e8bcf5a7740b4e34f83a6427b6824a1f84b1cd2c250fd9185f6b12cb7b*39f9d09f1483036ad5c27571e5f9251299d02e97de03cf00715281e7927230cc:1234Ó678

This could become a serious problem, because mist/ethereum wallet forces the use of utf8 and the user might only try to unlock/open/crack the account with the original password s/he typed/copy-pasted. Password recovery tools might try the wrong encoding (or only the encoding the user wanted/used) and fail just because a special character needs to be converted to a different encoding (it seems to be always UTF-8?).

Let's talk about problem number 2:
To reproduce this problem you only need a text-editor (or hex editor) and geth (go-ethereum).
The steps are as followed:

We are starting again with the same password file "pass.txt" with the password "1234Ó678" (without quotes, the hex characters are 0x31 0x32 0x33 0x34 0xd3 0x36 0x37 0x38):
We copy-paste the password and use the personal.newAccount () command within the geth console:
We find out that for some strange reasons we can't really copy-paste the password correctly into the geth console. The special characters are somehow skipped:

(note: I pasted the same password again directly as a "geth command" just to see it echoed by the console to make sure it really is what I copied, but remember: for security reasons you should of course never use a password as a command, it might end up in the logs etc, this was just a straightforward test to see geth fail to accept the special character)
We now already found out that geth skipped the special character completely, it was not displayed at all in the "password as command test"
We create a new file without the special character just to see if we can unlock the account also without the special character:

(note: now the special character 0xd3 is not used at all within our new password)
Try to unlock the account that we created with the different password (the one with the special character):
We see that the unlocking with the "wrong" password was successfully. This means that the only correct password is the one without the special character i.e. "1234678" (without quotes) instead of "1234Ó678" (without quotes).

Here you can find the UTC file for test number 2:
UTC--2018-03-03T19-30-40.672092700Z--b2869d5710c3be3f5e8bead54b9bf6cd304586e1.txt

This account can be cracked with hashcat (or other password recovery tools) with the password without the special character:

$ethereum$s*262144*8*1*b5f119b69fbd6a9d33debf739d44028a5fff97259f24a1ff6ca46c2388a23fbe*3c762411ee058f507a722dd1b99c4120b74a29cd9e48c389ec41ad336ca65b1f*c03c0b2a95af74df771a637297deb3f8b9eb5f3b474fab8d6b75363a91264dc7:1234678

Conclusion: you might think that both cases are edge cases and not what a user normally uses. On the other hand, I think we should not ignore these problems because their impact can be serious: for case 1 you won't be able to recover your password if you do not use the correct/changed character encoding and for case 2 you won't be able to test your passwords/problems with geth itself because geth seems to (at least on some versions/operating systems etc) not accept/paste the whole password but just parts of it (without special characters). Further, if your native language is not english or if you did use a password manager, special characters might be used a lot (also: in theory the 0xd3 is still a printable character, not outside the 0x00-0xff range)

philsmd on 3 Mar 2018

👍3 ❤2

I would expect answers from the devs (@evertonfraga, @marcgarreau, @alexvandesande, @frozeman etc)

Exactly. Ethereum needs to step up here.

my motivation about helping with this issue will become very tiny

We who are lost appreciate your understanding and intelligent mind in this issue.

anormore on 3 Mar 2018

Hi @philsmd, thanks for your effort on this issue! It's good to have technical conversations here again.

https://github.com/ethereum/mist/blob/ee1ddfaa6ccf5ff15170a2f7836ef057023ac3c1/tests/wallet/basic.test.js#L87

In order to clarify, that line fragment is part of an automated test script, which can't even be accessed by a regular user. So @Tguillaro, in short: "1234" isn't a default password.

This default password comes from a package we use (https://github.com/hiddentao/geth-private#via-command-line), and again, it's only fired from the build tests. At their readme page you can read:

"Default account password is 1234 :)"

I'm preparing the next release of Mist, and I'll come back to this issue, analyzing @philsmd response.

evertonfraga on 5 Mar 2018

Just read your whole post @philsmd, that's a great finding! We can now narrow our efforts to aim for those cases.

We've talked about this issue in the team's weekly meeting, and haven't given up. After the loads of work we've got in front of us, we'll come back full-force on this.

evertonfraga on 5 Mar 2018

👍4

@evertonfraga Thank you.

anormore on 6 Mar 2018

Regarding issue 1, just a quick quote from the JSON spec http://www.json.org/fatfree.html:

The character encoding of JSON text is always Unicode.

As such, I guess any account created via an RPC request will always have the password in UTF8 encoding.

karalabe on 6 Mar 2018

@evertonfraga you are right. As I said, I didn't investigate the "Run tests" menu in detail. I assumed that it runs several tests from the tests/ directory. Now I see that only the mocha-in-browser tests will be run when clicking on the menu item.
... but again, I do not understand how "1234" would be accepted by the dialog if the password length policy is rejecting all passwords smaller than 8

@karalabe I agree and I think it's okay that UTF8 is used. The main reason that I emphasized this "problem" is that many users here are trying to recover passwords and they might fail just because they are trying to find a password that contains a character like the 0xd3 character which is not the same as the character sequence that was used by mist/ethereum wallet/geth for encryption, i.e. 0xc393 instead. Both the length of the bytes and the byte values change.
Fortunately, good password recovery tools can handle different encodings (hashcat for instance has the --encoding-from/--encoding-to command line options for wordlists).
We all know that hashing/encryption normally works on a byte-to-byte level and therefore different bytes (like 0xd3 vs 0xc3 + 0x93) are different and lead to different results.
Ideally, mist/ethereum wallet could identify that the password that is sent to geth is different than the one that the user typed (javascript string object vs JSON object etc) and warn the user. Of course this warning must be designed very carefully and shouldn't confuse the user... so I'm not sure if it makes sense for a "normal" user. In theory, if there was an unlock account ("test password") or change password feature, the problem shouldn't exist anymore since mist/ethereum wallet should always use the same encoding and therefore unlocking within mist/ethereum wallet with the correct password (even if it has special characters) should always succeed.
The problem, as said, will therefore be only noticeable if you use external tools (and you don't know what the default encoding of mist//ethereum wallet is). The user might struggle very hard (weeks/months of cracking etc), just to find out that s/he already tried the "correct password", but just not with the "correct" encoding.

philsmd on 6 Mar 2018

The user might struggle very hard (weeks/months of cracking etc), just to find out that s/he already tried the "correct password", but just not with the "correct" encoding.

Yes, this is probably my case. What parameters would I use to test the different encodings?

And again -- thank you.

anormore on 6 Mar 2018

Great info. Regarding problem nr 2, I wonder if that isn't a windows issue. Are you at all able to paste special characters into the windows terminal? I can do it very well in my (linux) terminal @philsmd

Are you able to to this in your geth/windows terminal:

> JSON.parse(JSON.stringify({pw:"1234Ó678"})).pw == "1234Ó678"
true

Update

I made geth print out the attempted password.

> personal.unlockAccount(eth.accounts[0],"1234Ó678"

.. yields in geth:

Password attempted: 1234Ó678 31323334c393363738

Not sure where that leaves us.. I cannot (through geth console on linux) submit the sequence 0x31 0x32 0x33 0x34 0xd3 0x36 0x37 0x38.. it converts to unicode just as Mist would do.

The problem now is that this account can't be unlocked with the ANSI byte sequence 0x31 0x32 0x33 0x34 0xd3 0x36 0x37 0x38, but you need to use the UTF-8 bytes 0x31 0x32 0x33 0x34 0xc3 0x93 0x36 0x37 0x38 (note this now uses the hexadecimal character 0xc393 instead of 0xd3).

So how would the ANSI byte sequence ever be attempted -- all normal methods would convert to unicode just like Mist did.... ?

Update 2

Also tried creating it directly in geth using that 1234Ó678 password.

> personal.newAccount()
Passphrase: 
Repeat passphrase: 
"0x58d189f94bbbf8374421d3c3506f4c8a14079fd2"
> eth.accounts
["0x...", "0x58d189f94bbbf8374421d3c3506f4c8a14079fd2"]
> personal.unlockAccount(eth.accounts[1],"1234Ó678")
Password attempted: 1234Ó678 31323334c393363738
true

holiman on 6 Mar 2018

so what does it all mean to a crypto noob like me? do I need to give up on my ETH or should I wait for quantum computers? I'm so confused :(

lexie1 on 6 Mar 2018

@holiman yeah, I tried to copy-paste special characters within cmd on windows. There is absolutely no problem with that (outside geth). It only fails to work within the geth console. Even within the same terminal it works before starting geth, but after the geth process is started/running the paste of the special character in the geth console does not work anymore on windows.
I'm not able to paste the command within geth, the special character is skipped (as already mentioned).
Displaying the character (within geth and also within the developer tools/ Wallet UI) with this code works instead:

String.fromCharCode (0xd3)

(it's also not possible to copy this character even if geth just was able to display it with the String.fromCharCode () trick)
btw: the conversion of the bytes work like this too (the result is still 0xd3): // 110x xxxx 10xx xxxx

String.fromCharCode (((0xc3 & 0x1f) << 6) | (0x93 & 0x3f))

Yes, I agree that if you use utf8 everywhere (password managers, your shell/terminal, the not recommended password files that some users here used, for password crackers etc) you shouldn't have the problem of encoding. Problems of encoding of course only happen if your password file/dictionary file uses a local (non-utf8) character set (assuming you use a password with special characters) and you are trying to use a password in this system's default/local encoding vs the mist/ethernet wallet defaults one (utf-8).

I wouldn't recommend focusing too much on these encoding problems (understanding encoding is hard after all !)... but it's of course something that we should keep in mind and the affected users should try this encoding too when trying to use a password recovery tool (this of course only should be a problem if very special chars, non-ascii are within the password).

BTW:
it seems that when I do this, I still need to crack the file with 0xc393

personal.newAccount (String.fromCharCode (0xd3))

which is somehow interesting, but also normally acceptable (it's just weird, but encoding is hard after all)

philsmd on 6 Mar 2018

Well, I do have one example where a user used (potentially) a hebrew character set, which I've been trying quite a lot to find the password for. I have been doing various kinds of encoding/decoding attempts, but have not yet found the flaw. I'll keep trying, and revisit my previous attempts to see if I've missed something.

holiman on 7 Mar 2018

the problem often is the uncertainty. sometimes people think it was the case that they used this and that character/password, but it could turn out that the problem was completely different, like a completely different, often even very easy, password that was never tested because the user focused too much on a different set of password candidates or possible bugs.

btw this is how you could find out passwords that are likely to be affected by character encoding changes:

"Ó" == unescape (encodeURIComponent ("Ó"))

note: this just tests for non-ascii characters within the password, which often do not cause any problems but for some users it could have caused/cause some trouble like not testing the correct passwords with 3rd party crackers/recovery tools.
So in theory you could use kind of any javascript engine with utf-8 settings and put your password at both places where the "Ó" character is in the command above. If the result is false, you might need to test with utf-8 based dictionary files/attacks. Of course this shouldn't be done in any console that could log this command/password (like the default settings in geth) or any online computer/browser/website. Of course you should also not post your command/password as a reply to this post, keep your passwords secret!

With this command you will see the single bytes:

unescape (encodeURIComponent (String.fromCharCode (0xd3))).split ("").map (x => ("0" + x.charCodeAt (0).toString (16)).substr (-2))

Again, these are just some tests with character encodings and I do not think that most of the users here are affected by special character encoding problems. I think we need to troubleshoot deeper and get more detailed technical reports and test cases to find the actual bug that affected most of the users here (if there even exists such a bug. it's not 100% sure yet because there are very few posts with reproducible problems here but a lot of users that claim to have "the same problem", which is kind of a red flag).

For now we only found this:

new line characters are not included because of single line password text fields (will be replaced by spaces like most other browsers do). I also found out that there could be some additional characters like the tabulator/tab character that is "difficult" to copy-paste. On my linux system whenever I copy-paste a tab character to a text field it will be replaced by a space
the network change menu "Solo network" will automatically create new account (if none exist) with empty password (zero length string) without any notification (can be easily confused with a real account and the user does not know what the password of this account is because no password was set by the user)
default encoding of non-ascii characters will be utf8 and therefore the user needs to test utf8 password candidates if s/he wants to crack the UTC file
the geth (go-ethereum) console under windows has a problem accepting special (non-ascii) characters (on my windows system, I would be happy if somebody else can test this too and see if it works on other windows/mac systems). This might imply that several users who tried to unlock their account with the geth console (with e.g. the unlockAccount command) did actually already test the correct password but the geth console itself did not accept the special character paste and therefore the unlocking failed. This is a non-mist related problem, but still the impact could be huge for some users here which were told to test with geth because it is easier to test and no actual transaction needs to be created (mist afaik currently has no test password or change password feature).

of course there is the tiny possibility that at least some users are affected by at least one of these problems, but it seems that there must be at least one additional big problem/bug, because the cases above are way too easy to test and also very special
We also must take into consideration that at least a couple of affected users (maybe even the majority, but it's only possible to estimate this with high accuracy after some further testing were performed and maybe after some additional bugs were found or excluded) here just forgot the password and for them there is no problem/bug of Mist/Ethereum Wallet/Pre-sale webapp that prevents them from accessing their ether ... or forgot that they set a password

philsmd on 7 Mar 2018

I think with all my posts here, which for now mainly remained unanswered by the mist devs or they claim that they will look into it soon, but I still see no real contribution to this issue by the main mist/ethereum wallet devs, I just flood this thread and I won't get a reply to each and every concern/problem/bug we have found. My fear is that they will later on just skip over all the posts and miss or ignore very important discoveries we/I made.
On the other hand, I do not want to hold back the problems I find (that could somehow relate to this github issue) and risk to forget about them or risk to not be able to explain them in the future... so I will post here my finding anyways.

I thought about the problem of automatic account creation a little bit today and my thoughts went all about "how can mist/geth automatically create accounts also without clicking on the Solo network option".
... so I have a theory and this theory wasn't confirmed by me yet (I wasn't able to find a new account that wasn't created by me during this specific test) but devs could probably easily say "Yes this could have happened" or "Nope, impossible".

The main idea goes like this: there is some code in mist/ethereum wallet that tries to "detect" the network. Yeah, that's not a joke, there are some functions that try to detect if geth is running a specific network with a specific genesis block! see https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/interface/client/lib/helpers/helperFunctions.js#L218-L253
what I'm really worried about is that depending on the result of this check the "network" will be changed AND that the default option (which could be an exceptional case, a nothing-matched-but-it-is-for-sure-also-not-a-private-network case) is to default to the dev/privatenet network (see https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/interface/client/lib/helpers/helperFunctions.js#L246-L248) !

The change to a different network depending on the result of the detectNetwork () function call is here: https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/interface/client/templates/elements/nodeInfo.js#L51-L52

The somehow good part is that it should only happen if a valid genesis block was returned: https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/interface/client/templates/elements/networkIndicator.js#L24 which could filter out some further problems, but maybe not all of them!
Let's for instance assume that the list is not complete or the test network suddently changes to a new default network (and therefore genesis block) within geth etc...
Or what happens if the geth binary suddently decides to output the genesis block hashes all in uppercase etc. ... the default case will suddently be triggered, even if we are not at all on a private network.

There is even a second place where detectNetwork () will be called and the network could be suddently changed, see https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/interface/client/templates/elements/networkIndicator.js#L30 ... btw: it's also interesting why we have this duplication of code (fetching the genesis block and looking for errors and setting the network etc... this could probably be put in a separate function.... it's also interesting that one code uses try-catch, while the other place does not use try-catch !).

Let's talk again about my theory. What if the network was suddently changed to the private network for some users even if they didn't click on the "Solo network" option ? If we keep in mind that there is a problem (mentioned and explained in detail in my posts above) that whenever the "dev" network will be selected that geth/mist create a new account (it seems that this account always uses the empty password, but maybe also this changed in the past), it could happen that the user does not need to do anything special and whenever the detectNetwork () functions fail to detect that we are still on the main network or test network... it will just create a new account, because of the "dev" solo network, right?

I find this detect network feature quite error-prone and unsophisticated. I think there are better ways to communicate with geth. I think there are even network ids that were introduced to identify each and every network to prevent any confusion. I think that would be at least a slightly better approach than comparing some strings and defaulting to a network that a normal user would probably in 99.999% of the cases (if s/he is not a dev, of course) never use. The default/exceptional case should probably be an error message, because in my opinion the "Solo network" feature wouldn't be used by the average/normal user and for advanced users it should be explicitly selected, not just automatically determined because of the default case.

In theory you could also check both network IDs (web3.version.network) and genesis block hashes and only if both matches the network was correctly determined/detected.

At first I thought, why would Mist/Ethereum Wallet ever need to detect the network? it should dictate which network is being used.... then I figured that there is also the possibility that geth is already running and Mist/Ethereum Wallet only attach to that network. Again, this should probably be a separate/advanced developer option that needs to be explicitly configured by the user via some settings and it should probably not be the default behaviour in my opinion, because the normal user would just want to connect to the main network and geth should be started/controlled by mist/Ethereum Wallet, right?

I find it also very confusing that throughout the source code there are so many different "networks" all over the place, some of them probably just are the same network and should be called exactly the same way throughout the code. Here is a list (maybe not even complete): mainnet / testnet / privatenet / main / test / rinkeby / dev / solo / unknown
Some of these names for instance "dev", "solo" and "privatenet" could/should be probably named the same way in each and every source file (where possible)... or testnet and test .... or mainnet and main etc.

During my quick testing I also found out that the logic that is used by the user interface to display which network is currently selected is very bad and error-prone. This problem probably doesn't only affect the user interface but also other parts of the code who use the variables isMainNetwork, isDevNetwork etc.
Look at this code: https://github.com/ethereum/mist/blob/2875fd266926e43c79853760ea9748059fed2903/modules/menuItems.js#L487-L526
there is no way to make sure that only one network is selected. As far as I know the network selection should be mutually exclusive meaning that only one network can be selected at a time.
The problem is that when I switch from the main network to the "Solo network" I most of the time see something like this:

ethereum_network_not_mutually_exclusive

It's also possible to be on the test network and on the main network at the same time o.O how weird ist that:
ethereum_network_not_mutually_exclusive2

I somehow even managed to be on no network at all. I guess this is when Mist/Ethereum Wallet somehow set a "network" name that is none of the known one (but I couldn't easily reproduce this more than one time, but as you can see this also happened):
ethereum_network_not_even_one_selected

My recommendation is that this logic needs to be improved a lot and the conditions are that exactly one network is selected all the time. Not more than one network, also not less than one, but exactly one network must be currently selected and running/working, otherwise Mist/Ethereum Wallet should give an error message (and probably reset the "network" to the main network if the selected network for some reason does not work no matter what).

I'm sorry this is again a wall of text, but also a lot of interesting findings and possible bugs that could have led to the automatic account creation.
Again, for all affected users: the problem I found here and within the posts above does create an account with empty password, therefore this account should be easy to unlock/decrypt with the password of zero-length (empty password).
I think several ideas I mentioned will unfortunately be skipped/ignored by the devs because when they will eventually find time to catch up here, they will just skim through all the details pretty quickly :(
Hopefully they will proof that it wasn't a waste of time writing all of this and detecting all those possible problems and they proof that they take the matter seriously by investigating all the problems we mentioned so far.

Wow, I just found out that network / genesis block changes are not only a possibility, they are reality. It happened in the past, see: https://github.com/ethereum/go-ethereum/commit/a8ca75738a45a137ff7b2dfa276398fad26439da
As far as I understand this, the default test network/genesis block "suddently" changed to a new one. This would make the detectNetwork () code of Mist/Ethereum Wallet fail all the time if it is not 100% in sync with geth.

philsmd on 10 Mar 2018

👍4

Received message from philsmd asking for assistance, I hope I can help.
My response to provided questions.

Which version of mist/ethereum wallet/geth did you use? Version 0.9.3
Did you skip the initial account creation? Yes
Did you change/update between mist/ethereum wallet versions? No
How many accounts did you create (I created 3 additional accounts) and when exactly did you see these accounts (was there at least one account that was "automatically" created)? One account was "automatically" created. I first accessed it after initial syncing of Ropsten blockchain using GETH. Began mining Ether on Ropsten. Created second account, a third account, and fourth account to test a contract (wanted to send from multiple addresses). The first account (the one that was automatically generated when I initially accessed MIST) was receiving the mined Ether. When transferring Ether to the other accounts it wanted a password, but I had no password for the account - the account was already generated when I first logged in. Was not able to send Ether from this account. (Tried sending Ether without using password) Had to reassign a new Ether base for the miner in order to send Ether to other accounts.

If you really (100% sure?) have a test account and a random, non-very-personal password, do you mind sharing it? Sure, its: y3TZ%M|2KYPVHu#O5IDE+Nzm (NOTE: this password was not supplied to the automatically generated account, no password was provided. At least I did not intentionally assign a password to the account.)

maybe we can try to recover the password of this account to see what is going on? Sounds good, what do you need?
did you already try to use password recover tools on that specific account? No, its a test account.

res-Q on 17 Mar 2018

Hey @res-Q, glad you are here and trying to help the community!
For everybody else wondering where this discussion comes from: the initial post of res-Q that made me wondering about that specific case can be found here: https://github.com/ethereum/mist/issues/3403#issuecomment-373892023 (just for the context!)

If I'm not totally wrong the account with password "y3TZ%M|2KYPVHu#O5IDE+Nzm" is a different account and it's not the one that doesn't work, right?

So we have here again a problem with automatic account creation if I'm not totally wrong and it is "just" this account that doesn't work, right?

Did you try to unlock it with geth (cmd is: personal.unlockAccount (0x[ADDRESS]) ) or try to run the update account command: geth.exe account update ADDRESS ? maybe the password is the empty string (zero-length password)

We found out a couple of posts above that with the "Develop -> Network -> Solo network" option it could happen that an account with empty password will be created, do you remember clicking on the "Solo network" menu option ? ... or did you only use the main and test networks?

Did you click on the test network option when first starting Mist 0.9.3 ? Therefore, you never selected the main network at the beginning ? Did you ever switch to the main network?

When starting Mist 0.9.3 for the first time, did you let it finish sync or did you immediately click on "Launch Application" as soon as you could ? Did it already complete the syncing when you first saw the main menu and when the "automatic" account was first seen ?

Do you know for sure which address is associated with the account which was "automatically" created? Could you post the content of the UTC file here (only if you are 100% sure that it is the correct address and that it is only a test account, i.e. it has no ether in the main chain, make sure about it by using https://etherscan.io/ or https://www.etherchain.org/) ?
BTW: the UTC file can be found within the datadir keystore folder and can be opened by clicking on File -> Backup -> Accounts or Accounts -> Backup -> Accounts and after that you need to search the UTC file ending with the correct ether address within the "keystore" folder.

Do you think you can try to reinstall everything and see if you can reproduce the same problem? (by uninstalling mist/geth/ethereum wallet completely and also deleting the files in datadir - %APPDATA%\Mist, %APPDATA%\Ethereum and "%APPDATA\Ethereum Wallet" on windows). Please only do this if you have backed up everything important (and especially also the keystore files that we could use to troubleshoot... best would be a backup of all of these folders mentioned above from File -> Backup or Accounts -> Backup).

One additional question: did you use geth or any other ethereum-related software before you started using mist ? Maybe you already created a wallet file before even installing mist with a different software?
The creation/change date of the UTC files could also be interesting. Maybe you can tell us how old these files are in comparison to your mist installation date?

2 more question:

why did you choose to use the ropsten test network? the default one seems to be rinkeby. Did you swtich from main to ropsten ? or did you switch from rinkeby to ropsten?
which operating system do you use? why did you use geth on the command line ? when did you first use geth on the command line (before or after starting mist, before or after the automatic account was created? did you use geth with the --dev option ?)

philsmd on 17 Mar 2018

Fwiw, I've been using this little diff to see if I can detect any differences between 'attempted' password and what actually gets set in geth:

#git diff
diff --git a/internal/ethapi/api.go b/internal/ethapi/api.go
index 6525aa2..3089ab4 100644
--- a/internal/ethapi/api.go
+++ b/internal/ethapi/api.go
@@ -288,11 +288,15 @@ func (s *PrivateAccountAPI) DeriveAccount(url string, path string, pin *bool) (a

 // NewAccount will create a new account and returns the address for the new account.
 func (s *PrivateAccountAPI) NewAccount(password string) (common.Address, error) {
+       fmt.Printf("NewAccount attempted, pw %x %v", password,password)
+       return common.Address{}, fmt.Errorf("NewAccount disabled")
+       /*
        acc, err := fetchKeystore(s.am).NewAccount(password)
        if err == nil {
                return acc.Address, nil
        }
        return common.Address{}, err
+       */
 }

 // fetchKeystore retrives the encrypted keystore from the account manager.
@@ -316,6 +320,7 @@ func (s *PrivateAccountAPI) ImportRawKey(privkey string, password string) (commo
 // default of 300 seconds. It returns an indication if the account was unlocked.
 func (s *PrivateAccountAPI) UnlockAccount(addr common.Address, password string, duration *uint64) (bool, error) {
        const max = uint64(time.Duration(math.MaxInt64) / time.Second)
+       fmt.Printf("Unlock attempted, pw %x %v", password,password)
        var d time.Duration
        if duration == nil {
                d = 300 * time.Second
diff --git a/tests/testdata b/tests/testdata
index 2bb0c3d..37f555f 160000

Then using

/build/bin/geth --datadir /tmp/foo --nodiscover --maxpeers 0 --ipcpath ~/.ethereum/geth.ipc

And using Ethereum-Wallet-linux64-0-7-4

-/Ethereum-Wallet --datadir /tmp/foo/ --ipc /home/martin/workspace/wallet_recovery/geth.ipc

The password y3TZ%M|2KYPVHu#O5IDE+Nzm, and, basically, everything I have been able to throw at it, has not shown any problems. I am using the same modified client to perform bruteforce attempts against the keyfile I got from a user with locked funds, where I also use a hebrew charset for the attempts.

It might be a good idea to try the same approach on a windows machine....?

holiman on 19 Mar 2018

👍2

@holiman your hex string is wrong. If I hex decode 3078373933333534356132353464376333323462353935303536343837353233346633353439343434353262346537613664 I get this: 0x7933545a254d7c324b5950564875234f354944452b4e7a6d ( a ether address?)

It should probably be something like this 7933545a254d7c324b5950564875234f354944452b4e7a6d instead

update: it was hex encoded of an hex encoded string. if you hex decode it twice, without the "0x", I get y3TZ%M|2KYPVHu#O5IDE+Nzm
Not sure why you encode it twice.

philsmd on 19 Mar 2018

Ah, sorry, seems I messed it up a bit -- it's double-encoded. 0x7933545a254d7c324b5950564875234f354944452b4e7a6d is not an ether address, it's the hex string 7933545a254d7c324b5950564875234f354944452b4e7a6d

(I'll edit the diff above)

holiman on 19 Mar 2018

@holiman I came to similar conclusions with my extensive testings.

For instance I even made this particular test to see if generating a lot of wallets results in some wallets being uncrackable etc.

My idea was to not modify anything in mist/geth but let mist (or ethereum wallet) generate a lot of wallets with javascript for me and afterwards use an independent crack script (which shouldn't have any related problems/bug, because it is independent) to verify if the account (UTC wallet/json file) is valid/unlockable.

My javascript code (do not use this except if you know what you are doing, it will create a lot of UTC files and you shouldn't mix them with your important wallet files, always make backups of all your important wallet files AND be sure to remember your passwords. Never run any javascript code except if you are 100% sure what it is doing and that you really need/want to run it (in most of the cases you do not want and should not run any code from strangers)!) that I used/pasted within the Develop -> Toggle developer tools -> Wallet UI -> console is this one (please do not blame me for the code, it was just a straightforward test):

mycharacters = [0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xae, 0xaf, 0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf, 0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf, 0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff]

mycharacters_num = mycharacters.length

mypersonalAccounts = []

na = function (counter)
{
  mypasslength = Math.floor ((Math.random () * 25) + 8)

  mypersonalpass = ''

  for (i = 0; i < mypasslength; i++)
  {
    myindex = Math.floor (Math.random () * mycharacters_num)

    mypersonalpass += String.fromCharCode (mycharacters[myindex])
  }

  web3.personal.newAccount (mypersonalpass, function (e, res)
  {
    if (e)
    {
      console.log ("error detected: " + e)
      return
    }

    item = {"a": res, "p": (unescape (encodeURIComponent (mypersonalpass)).split ("").map (x => ("0" + x.charCodeAt (0).toString (16)).substr (-2))).join ("")}

    mypersonalAccounts.push (item)

    counter--

    if (counter > 0)
    {
      na (counter)
    }
  })
}

na (500)

to download the json that contains the address/password pairs ("a" and "p") I used this code:

var element = document.createElement ('a')
element.setAttribute ('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent (JSON.stringify (mypersonalAccounts)))
element.setAttribute ('download', 'json_accounts.txt')
element.style.display = 'none'
document.body.appendChild (element)
element.click ()
document.body.removeChild (element)

... and my independent perl crack script (do not use this for cracking your wallets, because it will be much slower than any other password recovery tool):

#!/usr/bin/env perl

# perl ethereum_scrypt_batch_check.pl /home/user/.ethereum/keystore/ /home/user/Downloads/json_accounts.txt

use strict;
use warnings;

use Crypt::ScryptKDF qw (scrypt_raw);
use Digest::Keccak   qw (keccak_256_hex);
use JSON             qw (decode_json);

#
# Start
#

if (scalar (@ARGV) < 2)
{
  print "ERROR: please specify keystore folder and json account list\n";

  exit (1);
}

my $folder_keystore = $ARGV[0];
my $file_accounts   = $ARGV[1];

if (! -d $folder_keystore)
{
  print "ERROR: Could not find the keystore folder\n";

  exit (1);
}

my $FH_accounts;

if (! open ($FH_accounts, "<", $file_accounts))
{
  print "ERROR: Could not open the account json file\n";

  exit (1);
}

binmode ($FH_accounts);

my $json_accounts = "";

{
  local $/ = undef;

  $json_accounts = <$FH_accounts>;
}

close ($FH_accounts);

my $decoded = decode_json ($json_accounts);

my @decoded_accounts = @{$decoded};

my $decoded_accounts_num = scalar (@decoded_accounts);

print "hurray! found " . $decoded_accounts_num . " accounts within the json file\n\n";

my $keystore_dir;

opendir ($keystore_dir, $folder_keystore);

my @keystore_files = readdir ($keystore_dir);

closedir ($keystore_dir);

my $count = 1;

for (my $i = 0; $i < $decoded_accounts_num; $i++)
{
  my $pass    = $decoded_accounts[$i]->{"p"};
  my $address = $decoded_accounts[$i]->{"a"};

  $pass = pack ("H*", $pass);

  print "$count) checking $address\n";
  $count++;

  $address =~ s/^0x//g;

  my @files = grep (/^UTC--.*$address$/, @keystore_files);

  if (scalar (@files) != 1)
  {
    print "address $address does not have a single matching file name\n";

    next;
  }


  my $FH_KEYSTORE;

  if (! open ($FH_KEYSTORE, "<", $folder_keystore . "/" . $files[0]))
  {
    print "ERROR: Could not open keystore file\n";

    exit (1);
  }

  my $keystore = "";

  {
    local $/ = undef;

    $keystore = <$FH_KEYSTORE>;
  }

  close ($FH_KEYSTORE);



  # parsing the keystore file

  $keystore =~ s/[\r\n]//g;

  my $mac = "";
  my $ciphertext = "";
  my $dklen = 32;
  my $n = 262144;
  my $p = 8,
  my $r = 1,
  my $salt = "";

  ($mac)        = $keystore =~ m/"mac" *: *"([0-9a-f]*)"/;
  ($ciphertext) = $keystore =~ m/"ciphertext" *: *"([0-9a-f]*)"/;
  ($salt)       = $keystore =~ m/"salt" *: *"([0-9a-f]*)"/;

  ($dklen) = $keystore =~ m/"dklen" *: *([0-9]*)/;
  ($n)     = $keystore =~ m/"n" *: *([0-9]*)/;
  ($p)     = $keystore =~ m/"p" *: *([0-9]*)/;
  ($r)     = $keystore =~ m/"r" *: *([0-9]*)/;




  my $salt_bin       = pack ("H*", $salt);
  my $ciphertext_bin = pack ("H*", $ciphertext);




  # scrypt:

  my $derived_key = scrypt_raw ($pass, $salt_bin, $n, $r, $p, $dklen);

  my $derived_key_cropped = substr ($derived_key, 16, 16);

  # SHA3 - keccak (needed for the "mac" check)

  my $mac_gen = keccak_256_hex ($derived_key_cropped . $ciphertext_bin);

  if ($mac_gen ne $mac)
  {
    print "Password not correct for address $address: $pass\n";
  }
}

exit (0);

so with the function call na (500), btw: na stands for new account ;), you create 500 new accounts for which you can later download the address/password pairs and verify them with the perl cracker (the perl cracker expects the keystore folder as its first argument and the downloaded address/password json file as its second argument).

My outcomes: even after I generated thousands of accounts, I didn't find a single wallet that can't be unlocked ! (even if the javascript password generation code includes the most weird characters I could come up with). As we already discussed we need to convert the password to UTF8 to make it unlockable/crackable (this is already done by the above javascript code, within the na () function, when it stores the address/password pairs).

This test result of course doesn't mean a lot (it just proofs that the communication between the API call and this specific version of geth seems to not be very buggy). It still could be that a specific (different) version of mist/geth or other factors (like the password dialog window, keyboard or system language etc) could lead to non valid accounts. Therefore the investigation needs to continue and we for sure need some better instruction on how to reproduce these password problems, because it seems somehow very difficult to reproduce it for an unaffected user (or for the devs too!?). I'm also currently convinced that at least a large number of "affected users" just forgot their password (or forgot that they set a password), but if we receive further evidence, maybe even a throw-away keystore file and corresponding password (or the detailed steps on how to reproduce it), we might be able to pinpoint it and convince ourself that this is indeed a mist problem (and not just a user problem, pebcak).

What I also planned to investigate is where mist sets the default charset to UTF8. I didn't see this in any template/html file that UTF8 was set explicitly (maybe electron is defaulting to utf8, but this could problably also depend on the user's system). I understand that json uses utf8 by default, but maybe the copy-paste already converted the chars to a different set of bytes/chars (or stripped some characters etc) before the json conversion even happens. Maybe it could happen that the system + password dialog are already messing up with the input (see smart quotes and character encoding conversions).

And of course, one of the big problems of mist/ethereum wallet is that there could be a specific version of geth (or combination of mist+geth) that triggered this probem. Unfortuntaly, mist just downloads the newest version of geth whenever this file changes https://github.com/ethereum/mist/blob/master/clientBinaries.json and therefore there are a lot of possibilities (even with very old versions of mist) that need to be tested and therefore we can't say that just because one combination of mist+geth seems to not trigger a bug everything is fine (worksforme!?). I think this geth update mechanism is quite buggy, what if a user uses a very old version of mist and still downloads the latest version of geth? are they always guaranteed to be compatible? Even if all combinations of mist+geth are known to be working for now, I don't think this geth-update-mechanism is future proof.
There will be some combinations of mist+geth that won't work in the future and therefore mist should somehow know which version of geth is compatible with this specific version of mist (and if there is really no new version of geth compatible with this version of mist, the user need to be forced to update mist too).

btw: I just saw that I forgot to mention that I also double-checked that also geth can unlock the accounts with:

geth --datadir C:\Users\phil\AppData\Roaming\Ethereum --unlock [listOfAddressesOrDeprecatedNumbers] --password json_accounts_pass.txt console

of course the file json_accounts_pass.txt must contain the raw passwords in the correct order. This is also very convenient for automatic password tests of multiple accounts (e.g. the 500 accounts generated with the na () test above)

philsmd on 19 Mar 2018

@philsmd: what if a user uses a very old version of mist and still downloads the latest version of geth? < That is an excellent question. I'm am certain that this is my scenario. I had downloaded MIST a few years ago, uninstalled it, then installed a new version. Maybe there are some artifacts left over???

res-Q on 20 Mar 2018

@res-Q I assume that in that case you already created a wallet during the old installation a few years ago and since it is dangerous to delete keystore files, the uninstaller didn't remove them and you probably didn't manually delete them.
In your specific situation I would suggest looking at the date/time when your operating system created these UTC--* file(s) within your file system and also look at the value after the "UTC--", the format is: UTC--[date]-[time]--, of these files within the keystore folder. If they are very old files, you probably already created some wallet files a few years back and just forget about them (and the password to unlock them should still be the one that you set a few years back and should still work).

philsmd on 20 Mar 2018

This is exactly the problem with issues like these "wrong password" claims: there are a lot of people convinced about a problem/issue but can't proof it and as soon as they see that there is another user also claiming something like this they get even more confident that it can't be wrong (pun intended).

Something similar happened here with this report from @res-Q : it seemed to me that there might finally be a user that can reproduce (or at least was recently affected by) the issue: https://github.com/ethereum/mist/issues/3403#issuecomment-373892023 .
... but it seems that the opposite was the case: s/he already had UTC files lying around from years ago and it wasn't the new mist installation creating random accounts with "unknown passwords" etc.

The other problem is that the devs do somehow (maybe even unconsciously) support all these myths and (presumably) wrong claims by not acting correctly and fast enough or ignoring problems for a long time until users get very angry, frustrated etc. This behaviour of the developers of not responding and not acting, somehow intensifies the problem/frustration and the users feel that they must be on the right track (they are convinced that their claim must be correct) because the devs seem to "have no clue what is going on".

Again, I invite all affected users to reproduce the problems (maybe with a new/fresh installation on a clean system, with no UTC* files already present on them. always backup your old keystore files AND independently make sure that you also remember the passwords), post here the screenshots or screencasts where you proof that this is indeed a mist problem and not just....

pebcak (Problem Exists Between Chair And Keyboard)... which I (unfortunately) think is the case for almost all the affected users... but on the other hand I also already proofed that there are some nasty bugs around (both in geth, for instance see https://github.com/ethereum/go-ethereum/issues/16286 , and mist, see posts above and https://github.com/ethereum/mist/issues/3762).

If we have some reproducible steps with full details (operating system, mist version, geth version etc) on how to suddently find an automatic account (besides the case from above) or a throw-away keystore file that can't be unlocked/used with that password for which we have screenshots of the password field etc, we might be able to pinpoint/discover the underlying problem.

Of course you could say that it's not the job of the users to reproduce/proof the problems, and I agree... but if it is way too difficult to reproduce/find the problem for the developers even if they try very hard, there might be also the chance that it is just pebcak (maybe forgotten password, old wallet/UTC file already present, user couldn't remember that s/he set a password etc).

I would also suggest this code change to the developers: that whenever mist is first launched and there are already accounts present (in the ethereum/keystore/ etc file and/or accounts announced by the geth process!), there should be definitely a warning/hint shown to the user that Mist found at least one old account and will "include" that within the account list (this dialog should be very user-friendly and explain exactly what it found and why this could be a problem e.g. if the user sends ether to this address even if s/he doesn't remember creating this account or doesn't know the password of this account). I think it should be pretty easy for mist/ethereum wallet to detect if it's the first time the user launched the application (maybe it's better that the user at least needs to see the main wallet window at least once before mist remembers that s/he already saw the warning/hint about the already-present-accounts-created-before-the-installation. I suggest to use the main window i.e. the WalletUI, not the splash screen as a "checkpoint" to verify if the user already has accounts present that were created before this installation and afterwards it should store that this check was now already performed and doesn't need to be performed anymore).

Unfortunately, if we have no clear proofs that there are currently any serious bugs/problems in mist (or were in the past, problems that magled the passwords etc), we can't really blame the software (mist/ethereum wallet). Another problem of course is also that there were some "display/logical errors" in the past like this one: https://github.com/ethereum/mist/issues/664 where there were not really problems with the password or keystore file themself, but just issues notifying the user about the "correct" problem. Errors like this are very evil because the user thinks that the password is incorrect, but the truth is that the problem lied somewhere else (e.g. other problems with sending transactions).
That's also why users should, if in doubt, also try other trusted applications to see if unlocking the account also fails with different software (not just with mist).

philsmd on 23 Mar 2018

@philsmd Here are the requested UTC timestamps. Your idea regarding the problem is correct. When deleting MIST it did not remove the keystore data from my first installation.

I would agree with your suggestion in order to help the new adopters of Ethereum MIST not lose their Ethereum. I would imaging loosing real Ether is a gut wrenching experience. Maybe updating some public user documentation would help?

I would also suggest this code change to the developers: that whenever mist is first launched and there are already accounts present (in the ethereum/keystore/ etc file and/or accounts announced by the geth process!), there should be definitely a warning/hint shown to the user that Mist found at least one old account and will "include" that within the account list (this dialog should be very user-friendly and explain exactly what it found and why this could be a problem e.g. if the user sends ether to this address even if s/he doesn't remember creating this account or doesn't know the password of this account).

There are still so many people that will be migrating to Ethereum that the less frustration the new user experiences, the better.

res-Q on 24 Mar 2018

I fundamentally disagree. My password was simply Pasword123!.

I set it to be simple, purposefully. I have it written down.

I participated in the ethereum presale.

Ethereum is bullshit, and I hope it burns down. The developers suck, and millions of dollars are being lost, which is bloating ethereum. Our problem benefits the value of other ethereum holders.

I’ll wait for the class action lawsuit.

AndyNormore on 24 Mar 2018

Let me jump in here to clarify a couple of things and give some perspective.
I'm working on Mist on password related issues which have the highest priority on our list.
Since I'm new to the team, I wanted to get a better picture about the current situation for myself. I did an analysis of the issues and would like to share some results with you, answer some questions and make our internal work more transparent:

How many people are affected?
Even though this issue is the one with the most comments (~300), in the end my spreadsheet had "only" 30 names on it. Side note: ~ 10 comments per user.
About 80 people participated in the survey /google form. Most of them are also active in this discussion and therefore counted twice.
So even if some comments falsely claimed it: we are NOT talking about hundreds of people that "have the same issue" or "experienced the same bug". I acknowledge that there are probably more people out there who didn't care enough or didn't know how to reach out to the team. But it is quite unlikely that this is in the range of thousand(s).

Are we seeing an anomaly here?
Statistically, it is hard to make an estimation since we are not tracking users or putting unique identifiers on anything. But geth and Mist have millions of downloads, so I would say 100 / 3,000,000 or even 1K / 3M is not statistically significant for this kind of problem. There is a reason why Web services have a "forgot password" button and many people are using it. Currently, it is rather likely that indeed most of the people here made a mistake than a malfunctioning of the software.

Does it mean we are not taking this serious?
Absolutely not. As mentioned before it has top priority despite the fact that the majority of users is not affected. We are fully aware of the fact that there is a lot of space for improvements in Mist and want to exclude the tiniest possibility that even a hand full of users lost their Ether due to a bug in the software. This is why the team was extended and this why this issue is being investigated.

What should I do?
So my advice to everyone is to calm down a little bit and start to think logically: it makes a huge difference with which mindset you approach the problem.

Fill out this form if you haven't yet:
https://goo.gl/forms/jznmHV6Fpui7Ijds1

Only write into this issue or open other issues if you have real insight. Otherwise leave your email in the form and wait for notifications.

And since your resources (time, money) are probably limited, you should tackle this situation from two sides and plan how to use your resources and target your efforts best:

What if indeed you made a mistake / something atypical? (statistically likely)
how can you reproduce your own behavior / hack yourself?
What if the software made a mistake? (unlikely)
how can you demonstrate your unique, individual circumstances that lead to this unusal situation?

If you follow a strategic and objective approach your chances will increase dramatically. Brute forcing billions of combinations should be the last resort.

Do we know of any working solutions / "fixes"?
From the 30 people on my sheet two have been able to recover their wallets and so far I've heard of 1-5 more people who initially where 100% convinced about their password / some other variable, did something fundamentally different or something they had excluded as possibiliy and had success.
Ethtester's story https://github.com/ethereum/mist/issues/3513#issuecomment-362434112 is a great example, quite inspiring and helpful:

"This was obviously a password that I had created using some online password tool since like I said, I have always created generally weak passwords myself. [...] Now I was 1000% convinced that I had not been asked or entered a password at the time, looking over my notes, I see that the day I created the wallet was extremely busy for me..."

So one winning strategy could be to roleplay the day. Here are some tips:

Go through notes, diaries, talk to the same people about the same things you did that day. Wear the same clothes. Investigate log files. Open documents that you opened on that day and reproduce as many details as possible. Plan your actions and try to remember every little step. Take notes.
Try to reproduce your stress level. Are you acting differently in stressful situations?
Important: Have in mind that you might want to use data recovery or forensics so don't use the old machine for this. Create a test environment. In general: if this wallet is important for you, you should not touch the machine at all. Keep you backups and notes safe and talk to an expert.
Here is an interesting story that could spread hope: Some machines get infected with malware or if you are in IT maybe you experimented yourself with some tools that collected extra data. I've heard of someone who was able to recover a different kind of password because there was a "keylogger" running on his computer in the background logging every keystroke. Scary? Yes. But the point is: don't underestimate the amount of information that the system or software (search history, log files) collects and stores. Maybe there is information on your machine you didn't even think of.
Many people don't even know that browsers store passwords for online services and that these passwords can be viewed in plaintext. Check if your browser has old passwords stored from this time and use them as input for your brute force or just as a reminder for yourself.
DONT send your information or data to people who advertise in this thread or claim they found their password with a mysterious unknown / custom tool. Contact an expert or if you feel unsafe reach out to someone from the team and we might be able to assist you in finding help or can help you directly. Team members usually have [email protected] addresses. My name is philipp.
Think outside the box
If your password is a number maybe a birthday or phone number think about people you interacted with during that time. Maybe it is not the birthday of your current girlfriend but the last one (stupid example) - I think you get the point.

How long did it take to process the thread and what was the information gain?
I spent about 3 hours going through the issues, following the links writing everything down and putting together pieces of information. This time could have been spent on improving the software or writing automated tests. The amount of valuable information was in no relation to the noise.

The people that contributed the most (like @philsmd) are not even affected themselves.

What are the main takeaways?

As it stands there is chance that a chain of unfortunate events caused your a weird behavior in the software and your situation. The bad news is: it is rather unlikely.

For now, I ended up with this list of potential sources and we will test these cases and try to provide assistance in resolving issues related to them.

Character Encoding - "the copy / paste problem"
Mist uses utf8 (which is standard) character encoding and so does geth. And it is unlikely (not impossible) that information got 'lost in translation' somewehere in between. But we cannot speak for any other software that you might have used. If the input was generated or created with the help of external tools such as a text editor, password manager or even a terminal etc. that used a different character encoding, there is a chance that something like 'abcè' has encoding ambiguity and can numerically be represented as (simplified) '1|2|3|9' or '1|2|3|7'. The more exotic the character (=not abc..xyz, 1,2,..9,0) the higher the probability that it is a problem. Things like !"§$%/()=? should be no problem since they are part of a standard set and encoded with the same values in most encodings, languages, keyboards etc - but we will run many, many tests to prove it.
~40 people in the survey answered that they had used special characters and 75% used standard inputs (keyboard and language). All of the special characters are in the range of '#!"§$&/()=?@_.' - so the chance that there was an encoding problem due to copy / paste problem is very, very small but not impossible.

Resolving these encoding problems should be fairly simple if you know the password. Testing every encoding for your password should not take longer than a couple of minutes and most tools should support the option.

Character Transformation - "copy / paste & input problem"
This one is a little bit more tricky and serious. HTML input fields have their own logic how to treat input. Single line fields sometimes don't support multiline characters. So something like
'
abc'
could end up as '\nabc" or " abc" or "abc". Please note that in example 2 the newline character got internally transformed to a space " ". These effects are possible if you wrote the text in a multiline environment (text editor) first and copy pasted it.

Similar effects can happen with characters that are the result of multiple key presses. Something like ` + e can end up either as one character è, as two ( ´, e ) or just e. We are heavily investigating the possibilty of additional effects. Please have in mind that this can vary between different operating systems and browsers. So if you took part in the presale and used an input field in Safari on Mac it might behaves differently to say Windows and Chrome. And have in mind that this is NOT a bug in Mist, but inconsistency between different browser implementations.

The good thing about these issues is that unless a vendor changes the behavior or fixes something you should be safe. As long as you're using the same input method (e.g. Mist, Safari) in the same way, it should all lead to the same results no matter what and should just work.

It should also be quite simple to create rules for a brute forcer to try combinations of the password with varying numbers of leading and trailing spaces or newline chars. The processing of a reasonable amount of combinations should not take longer than 1 day with a good rule set.

Keyboard and environment
I have multiple keyboard layouts installed on my machine that I can switch between with a key combination. It could be that you did not use your own environment and "qwerty" became "qwertz". Or capslock was active and "abc" became "ABC".
Keystore files
This class of problems has many facets: Maybe your original environment had already accounts on it or the one you're testing on right now came with existing files. Maybe a colleague or family member used the computer in the meantime? Different programs use different paths to store information so it could also be that you're just logged into the wrong user account or directory.
In any case: your password will not work when you are working on the wrong file. I've seen people try to open their neighbour's car on a parking lot so this is actually a quite likely scenario.

Make sure that you know about all keystore (UTC) files on your computer. If there is more than one double check that you are trying to unlock the correct one. Compare the timestamps. If you think that your file might got overwritten use recovery tools or talk to an expert. Again: use a test environment not the original system

Under certain circumstances it might happen that Mist auto-creates wallets for you. E.g. for development and testing purposes. Such files are easy to test and should be unlocked with empty passwords. However they are not meant and should not be used regular wallets. If you transferred funds to a test account wallet they are probably lost but there might be a tiny chance to get them back.

This scenario is possible if the user switched networks or used other developer options.
Was there another instance of geth or 'node testrpc' running on the computer during the time of password creation?

Finally:
Is there a 'wrong password bug' in Mist?
A bug is if the software behaves incorrectly and in a way that is different to the specification. So no, Mist does NOT act weird or in a different way it was designed to. The developers are not surprised and it is not like we finally found the bad line of code that does all the things that were not intended. But we are still searching for these kind of things.

Was it a bad idea to allow invisible and non ASCII characters for passwords without trimming or further restrictions?
Yes.

Will we change this in future versions and issue more warnings to protect users from themselves?
Yes.

Is this the reason why you're seeing the 'wrong password' screen?
Probably not.

Will we try to assist people to recover their passwords in these unusal cases?
Absolutely,

PhilippLgh on 24 Mar 2018

👍6 ❤1

That sounds like very good news for affected users: there is at least one person on the ethereum/mist team that feels responsible for addressing/troubleshooting problems like these. That's already a good first start to get things sorted.

@PhilippLgh I'm not a big fan of statistics like these (because there could be so many factors that you didn't consider and therefore putting these numbers into play could be a little bit misleading) ... but to be fair you also mentioned yourself that there might be "a couple" of more users affected or other problems that also contributed to the "wrong password" error for several users. I agree collecting some numbers/amount of affected users could help a little bit to get an overal idea to find out how many users were recently affected and "care" about reporting/troubleshooting the problem.

I'm also wondering which github issues were considered for these statistics (only very new ones?). As you can see here there is a huge list of "password" related problems: https://github.com/ethereum/mist/issues?q=is%3Aissue+sort%3Acomments-desc+password or maybe better this one: https://github.com/ethereum/mist/issues?q=is%3Aissue+sort%3Acomments-desc+"wrong+password"
as you can see there are a lot of old issues too, several old-but-still-open issues should probably be merged/deduplicated/closed, but they probably shouldn't be completely ignored (because it could still be that one single comment within these huge set of comments could lead to find a possible serious problem/bug, like the one I recently found in geth: https://github.com/ethereum/go-ethereum/issues/16286)

... to conclude, I wish you (and most of all the affected users) good luck in finding the root cause of these problems and I will probably keep reading updates here, just in case I could still be of help in the future

philsmd on 24 Mar 2018

👍1

there is at least one person on the ethereum/mist team that feels responsible for addressing/troubleshooting problems like these. That's already a good first start to get things sorted

Just to be clear, I am the security lead for Ethereum Foundation, and also a geth developer. I have spent countless hours on these issues over more than a year. I don't like the assumption that we've been ignoring these tickets all this time.

holiman on 24 Mar 2018

👍8 ❤2

And what about presale wallets purchased from your website? It’s not possible to diagnose anything now, yet the problem persists.

AndyNormore on 24 Mar 2018

@holiman I see that my statemant was a little bit misleading. I apologize, I didn't meant to accuse anybody. I just wanted to say that I appreciate that additional human resources will help to solve/merge/deduplicate/close the many "wrong password" issues for mist etc. It's very obvious also for an external human being (me for instance?) that the security lead of the foundation can't do all these (important but) time consuming tasks and still work on more important bugs (bug bounty program etc) and need to speak to/manage a lot of people/projects/conferences etc... It's for sure a good thing to delegate problems like this to other people who can work on this almost full-time.

@AndyNormore I'm not sure why you keep saying that the presale keystore file generation can't be diagnosed. As we already mentioned a couple of times it is very easy to do. After all it's just html and javascript that runs in your browser and you even have the commit history to see what was changed when:
https://github.com/ethereum/mist/issues/3513#issuecomment-366007905 , https://github.com/ethereum/mist/issues/3513#issuecomment-366013278 , https://github.com/ethereum/mist/issues/3513#issuecomment-369141328
The only thing you _could_ claim is that you can't be 100% sure that the exact same code found on github was also used 100% identical on the ethereum.org page, but I don't think that is something you should bother about. I think the solution to unlocking your presale problem won't go into this direction at all. The solution probably is much, much easier and at the end it could turn out to be damn obvious (like a appended/prepended character because of the password policy or a very different but simple password that you never considered that you used it). I also think that your case is not related to this github project at all (mist), because your wallet file was not even generated by mist and mist didn't even exist at that time etc. I'm not sure why you compare your problem with these mist problems that much. It seems completely unrelated and it most likely is.

philsmd on 24 Mar 2018

👍2

The only thing you could claim is that you can't be 100% sure that the exact same code found on github was also used 100% identical on the ethereum.org page, but I don't think that is something you should bother about.

You must understand that it's possible, right? I've tried trillions of combos now. Nothing. I'm telling you man, my password was like, Ethereum123! so I wouldn't forget it. Something simple to crack in case I forgot it.

There's something else going on here, and because Ethereum has very little practical movement on this issue, I will keep bringing it up. I believe it is something on their end.

I am not alone in PreSale wallet problems.

Everyone here is so quick to dismiss this problem, or that problem. What should I do, create ANOTHER post regarding password problems so they can ignore it?

No.

I will sit here and bitch and complain until some one actually admits a fault, and goes back and does something.

But, that's probably not going to happen, so I will continue to voice out that Ethereum can't be fully relied upon to manage Crypto. To this day, right now, there are password bugs out there that will seriously harm some one -- and I think people spending real world dollars should be aware of this.

I'm sure that in a few years these issues will be resolved. But damn, I've seen better support from collection agencies.

Anyway, I'm lurking on this issue, but I'm pretty much out of Ethereum now. Good luck to everyone else who is stuck.

AndyNormore on 1 Apr 2018

Hi all,

I don't quite know where we stand and if any head way has been made. I have been quietly following for a while as I simply didn't have anything prominent to present. I have been trying to replicate the issue but have failed.

I still have my few Eth locked away. As previously mentioned I still have the screenshot of the moment I created the password and backed it up. It still wont work, so I just don't know what else I can contribute.

Is there any headway that has been made or are we still where we stood in December when I first brought it up..?

pavneet09 on 16 Apr 2018

👍3

In my opinion the main problems here are the:

problem of reproducibility (if a problem is that wide-spread it should be reproducible somehow at least for some people with specific setup/settings etc)
problem of credibility (do users only claim they are 100% sure about the password or are they really sure?)
problem of distraction and strange/unproven claims (I read a lot of comments of wrong passwords within this repository and many theories/myths are quite distracting, something like "if your password contains the symbol @ you can't unlock your account", "it happens only with the etherbase account", "it happens only with the second account", "it happens only after receiving some ether with the address", "it happens only when sending out some funds" etc... many users agree and state that they have exactly the "same issue" even if the theory could and probably is very unlikely)
problem of testing (in my experience testing different combinations of mist+geth is VERY,VERY difficult, cumbersome)
problem of no activity/responses/actions from mist developers
...

For instance, even you (@pavneet09) have admitted that you are not 100% sure or there could be the slight probability that it was a human error also in your case (see https://github.com/ethereum/mist/issues/669#issuecomment-354853833): "I am giving myself the human error dilemma and still thinking I did something wrong".

For point 3, I agree that the problem could be that the user only notices that there is a problem with unlocking accounts when sending out ether for the first time (or publishing a contract etc)... but this doesn't mean that the problem wasn't there beforehand. It's easy to test if the UTC file changed (you can compare/diff them, compare timestamps etc) or check if the backed up keystore file is unlockable while the "current account" in mist is not. You should also use 3th party tools to double-check if these tools are able to unlock the account, e.g. directly with the geth executable or myetherwallet/mycrypto etc. For me it seems that several theories are just distracting claims and as long as they were not confirmed (successfully tested ... and do not get me wrong all theories should be tested and it should be guaranteed that someone tries to reproduce them), we should not give them too much attention.
For instance, I think it's quite unlikely that the UTC file suddently changes and fails to work even with 3th party tools after a transaction was received etc... it is just the moment the user first realized that there is something wrong, because s/he can't use/send those ether out.
I also want to mention the possibility that it is possibile to set up a private network or play with the test networks by mining and sending transactions without risking to loose any money etc. Therefore, it is not impossible to also test if sending out funds is working with a newly created test account (I saw these claims a lot while reading some comments that sending ether to test this theory is very costly. It is not, as long as we assume that the test networks and private networks behave the same as the main network)

I invested some time to try to test several combinations of mist and geth, but this is very tedious / cumbersome ... and in fact very easy to test old versions incorrectly (easy to mess up the testings!).
In my opinion, you would need to test an old version of mist/ethereum wallet with the "correct" version of geth shipped at that time and therefore also the correct (old) version of the file clientBinaries.json.
The problem is that those files are automatically downloaded after you "install" and launch mist/ethereum wallet and mist/ethereum wallet always download the newest version of clientBinaries.json and the geth version mentioned within this newest version of clientBinaries.json.
To complicate things even more, even if you try to force the use of an older clientBinaries.json+geth combination, mist/ethereum wallet try to update these when launching the application. Therefore it's easy to mess up the testing and test the wrong combination/versions.
I think this update mechanism and geth<->mist relationship is kind of weird/broken. I think that it would be better that the clientBinaries.json states which version of mist are compatible with which versions of geth or have different clientBinaries.json files depending on the mist version etc. Currently almost all combinations seem to be possible and the newest version of geth is downloaded even if mist isn't compatible with it (yeah, also the opposite is true for instance I saw the error message of geth complaining that --syncmode is not a valid option if you try to use new versions of mist with old versions of geth etc).
How I tested this is to go to the release version page: https://github.com/ethereum/mist/releases and download the preferred version of the ethereum wallet installer, let's say 0.9.2 from https://github.com/ethereum/mist/releases/tag/v0.9.2. Install it. After that, you need to click on the latest commit hash of this version (for 0.9.2 it is 369713b, shown on the left side of the release page: https://github.com/ethereum/mist/releases/tag/v0.9.2) and follow the link e.g. https://github.com/ethereum/mist/commit/369713b8e3ed7450418333ba985bdfe2b26307fb . After that you need to click on "Browse files" on the top right of the github page. We see this page: https://github.com/ethereum/mist/tree/369713b8e3ed7450418333ba985bdfe2b26307fb . now we need to click on the clientBinaries.json file and click on "Raw", we see for instance https://raw.githubusercontent.com/ethereum/mist/369713b8e3ed7450418333ba985bdfe2b26307fb/clientBinaries.json . I afterwards downloaded both the raw clientBinaries.json and the geth version mentioned within that file for the correct operating system and architecture. You need to place the downloaded clientBinaries.json file into the %APPDATA%\Ethereum Wallet\ folder and the geth executable into %APPDATA%\Ethereum Wallet\binaries\Geth\unpacked\ (the extracted .exe file must be within the unpacked folder).
I disconnected the computer from the internet to avoid that mist is downloading the newer version of clientBinaries.json and/or geth and/or mist at the launch of the application.
As you can see, this testing is very tedious and error-prone, not sure if everyone trying to reproduce this failed just because they didn't know that mist/ethereum wallet downloads the "wrong" (newest) version of geth and therefore the testing is kind of wrong/broken (because you test the wrong versions if you allow updates/downloadds of mist/geth/clientBinaries.json etc).

I'm wondering if the developers considered this "version conflict/mismatch" problem when testing, @PhilippLgh, @holiman, @marcgarreau etc. It would also be great if this issue receives more status updates from the devs and I don't mind if it is just "these past weeks we tested to reproduce theory x,y,z by doing these steps a,b,c,d but couldn't reproduce a single wrong password problem".

I'm also wondering why there are now (seemingly) a lot less new comments or new issues regarding wrong passwords... but this could have many reasons, like: there could be only some combinations of mist+geth with password bugs (and maybe newer versions do not have these problems), new users didn't noticed the problem yet (they didn't try to unlock the account yet), the users read this issue and tried to reproduce but also failed to reproduce, many users are not 100% sure if it was a human error (pebcak) and therefore just don't report it/comment, ether price is no more at all time high (ATH) and therefore less users are eager to unlock the accounts...
It's actually interesting that there was a time were the creation of new comments/issues was very high. Maybe someone can create something like a heatmap and find a relationship to release dates (of mist/geth) or ethereum prices etc. ... but... I think it could be difficult to find a relationship between new releases and password problems because it seems the users normally created the account much earlier compare to when they tried to unlock it (hodlers... which created the keystore file with a much older version of mist!?).

philsmd on 19 Apr 2018

👍1

@philsmd

I have been thinking the same about how very few new error reports have been coming in.
And yes, I did admit that it could be human error till some percent, but I also cited that I have a habit of always taking a screenshot of the crypto password. And yes, even in my case special characters were involved as well as it being the second account.

I even volunteered to give my account to be tested upon at one point of time with the json file and password that I have, if only some hope was given that I might receive the ether at the end of testing.

My logs can very easily be seen as well, as of how I only had Ether coming in, until I tried to send it out for the first time that I realized this was happening.

I test many combinations of Geth and Mist.

I'm not as coding worthy, but have tried a couple of password tools but with no luck.
I'm still hopeful that maybe this can soon be realized as an error or can be replicated and shown.

pavneet09 on 23 Apr 2018

@pavneet09 If you are willing to share your json-file and password candidate(s) with me, and it is 'small enough' for me to feel comfortable with it, I'm willing to make an attempt at recovery. However, if the value of that address is very large, I'll have to decline, since I do not want to be exposed to the risk of being sued in case the ether ever goes missing (not due to my actions).

Another user has also sent me his/her encrypted json file, which I have (so far) unsuccessfully tried to unlock with various strategies.

You can contact me by PGP-encrypted email. My PGP-key is listed on https://geth.ethereum.org/downloads/ . Please do not send any sensitive information just yet.

holiman on 24 Apr 2018

Update: we are still testing. If someone feels like they are having the same issue please fill out this form
https://goo.gl/forms/jznmHV6Fpui7Ijds1

And please don't write "a story" about what could have happened to keep this thread clean and manageable. Various geth / mist combinations and hypothetical incompatibilities between the two are not top priority during testing - we completely rely on reports (google form) here and test only relevant combinations.

PhilippLgh on 24 Apr 2018

Hi @holiman ,
I'll gladly share the details with you if you feel comfortable doing so.
Contacting you on the mentioned channel. Thank you.

pavneet09 on 24 Apr 2018

Hi I am in the pretty same case can I send my file as well ?

sebd-davra on 24 Apr 2018

You can contact me over email, but please don't send me anything sensitive.

First I want to ensure that we can communicate encrypted, and secondly I want to ensure that nobody sends me something too valuable. Thirdly, I don't do cracking for it's own sake, only to investigate potential issues that could have arised in the pipeline between typing a password in and a keystore being encrypted. So I'm not interested in cases of "I forgot my password".

holiman on 24 Apr 2018

👍3

I would like to emphasize again that the encryption algorithm of the "seed" allows to verify that the password is correct even if the whole encrypted seed is not known to the password recovery dude.
You normally do not need to share the whole json file or the whole encrypted seed ("encseed" or "ciphertext") just to verify if the password is the correct one. (I agree that for testing purposes it could help to troubleshoot in some very specific and limited amount of cases with throw-away accounts with very small amount of ether etc)

The two possible ways (they are independent) to do this without exposing you to the risk of the password recovery guy taking all your funds is:

AES (pkcs7) padding attack (padding at the end of the decrypted data)
known charset attack (e.g. hexadecmial characters were encrypted instead of binary data)

Please read about this ideas/techniques mentioned above or on the hashcat forum (https://github.com/ethereum/mist/issues/3513#issuecomment-366007905 etc and https://hashcat.net/forum/thread-6405.html).

Don't send the data (let alone the json files) over unencrypted emails and do not send the data to random people you do not know yourself or which are not 100% trustworthy.

philsmd on 24 Apr 2018

Some updates... I got the file from @pavneet09. it's only about 3 ether, which I'm comfortable with.

I have built a custom geth, and tested

All sorts of one-byte replacements in password
All sorts of one-byte insertions
All forms of cropping password
All 1-byte and 2-byte prefixes to password
All 1-byte and 2-byte suffixes to password
All 1-bit bitflip-corruptions on the fields (salt/ciphertext etc).
No success so far, unfortunately.

I disabled MAC check on all tests, and instead of checking MAC always calculate the address and see if it matches the expected (because the MAC might be corrupt).

Also, I just found out that the same password had been used on several occasions, which is very interesting, since it means that (in at least this particular instance), the corruption (assuming the file is corrupted) is not due to the encoding-issues with particular characters in the password.

I'm not sure what the best way forward is. A few ideas:

I will investigate more the potential effects of bitflips due to non-ecc memory corruption, or filesystem corruption.
When creating an encrypted json blob, geth should immedately try to decrypt it, to ensure that it can be decrypted with the password. (?)

holiman on 2 May 2018

👍4

@holiman Nice work! So you mean that several seperate people that not know eachother have the same password?

ontheronix on 2 May 2018

I have this issue as well. My issue seems to line up with #3436. I'm 99% sure that I clicked "skip" while setting up my wallet, and even if I didn't, I tried every possible password that I would use.
Running the wallet on a 2017 Macbook Pro running OSX.

Planning on installing the wallet on another computer (the wallet is taking up too much space on my laptop anyway, and has practically filled up my 256 GB HD) and trying to move my wallet files over to the new computer to see if that will help. I want to start fresh on a new computer and see if the issue persists.

I'll keep editing this post as I do research and eventually try to redownload the wallet.

I'm no pro, so I do have some questions:

Will I run into any issues saving the wallet log to a 5TB external HD?
_Did some research, not as easy as I'd expect. I'll have to dome playing in Terminal to get this to work.
Found a lot of people suggesting this video (Windows)
Found this tutorial for Mac._

Does the node have to be completely up to date for me to attempt to send ETH to see if the bug has gone away? Does it have to be completely up to date for me to import the wallet files?

Notes:
There's some basic helpful info in #2662 about transferring your wallet to another computer. For more detailed instructions on backing up wallet files, check here.

VCBCN on 3 May 2018

Hi @ontheronix
No, he meant that the same password was working on many different accounts created by me or already in use, except the second account.
After the error, I even tried to recreate the scenario and kept creating more accounts just to replicate the error but couldn't.

pavneet09 on 3 May 2018

has anyone who is sure they have the correct password tried entering the password & pressing the space bare once (even try pressing the space bar before entering password). Because as some may know it is possible to copy & paste 'white space' before & after copy&paste.

7iain7 on 4 May 2018

@7iain7 I have tried all of my possible passwords with a space after them, to no avail.
Also tried switching the capital and lower case letters (since sometimes if caps lock is on, and you hit shift, it'll swap to lowercase). That also didn't work.

Keep in mind that I'm almost positive that I skipped password creation when making the wallet.

VCBCN on 4 May 2018

I created a wallet on 5/25/2016 (v0.7.4) and I'm 99.99% sure it never asked me for a password. I keep very careful records and I have a record from that day detailing the amount of Ether, price, etc. but no password. I'm very sure this is a bug in the software. I'm going to be monitoring this thread closely, hope a solution is found soon.

hermangottlieb on 6 May 2018

Hi,
Since I generally do not want people sending wallets to other people, I have put together a little test-utility which does some basic tests against a wallet that seems to not work.

You'll notice that it is not merged to master, but in my personal repository. This (and the warnings when starting it) should alert you that the tool is on a kind of 'developer pre-release'. It will print out potentially sensitive data on the screen. It has not been audited.

It is not a password-bruteforcer. It's actually a bit slower than ordinary geth, because geth checks the MAC and aborts the key derivation if the MAC fails. This tool continues anyway, and always derives a key (and address), in the unlikely but not impossible event that the MAC is corrupt.

It checks a few cases of extra prefixes and suffixes (linebreaks, whitespaces) and croppings (password beign truncated), and also tests all 1-bit bitflips on the encrypted fields.

I have not been able to recover any wallets with this tool, so I'm very curious to hear if it helps anyone -- but yeah, don't hold your breath :/

The code is available here: https://github.com/holiman/go-ethereum/tree/recovery/cmd/recovereth . Feel free to make PR:s or suggestions about what to add. If it indeed helps people, I would guess that we'll merge it into main at some point.

holiman on 7 May 2018

👍3

@holiman How do I run this file? I have Go installed on Windows.
When I try to run or build it, it says 'expected 'package', found '<'

ontheronix on 12 May 2018

Go into the folder (cmd/recovereth) and type 'go build .' should do it

holiman on 12 May 2018

@holiman That's what I was trying to do, but it throws the above error.

ontheronix on 12 May 2018

@ontheronix You downloaded a html-page...

bvdbos on 13 May 2018

Four hours later. Building the file is no problem. However, how do I run it?
Seeing line 365 : "recovereth.exe keyfilename"? And seeing line 44/52 adding "passphrasename=flatfile.txt" to it? So, for a keyfile X.json and a passwordfile Y.txt :
c:\users\bas\go\recovereth\recovereth.exe X.json passwordfile=Y.txt ?

bvdbos on 13 May 2018

Yeah, that or switch the args around (the flag (passwordfile) might have to be first)

holiman on 13 May 2018

This might help some of you.
I was having the same problem. Could not send ETH through Ethereum Wallet. As most of you I was sure my password was correct. After struggling with this for some time, I realized I somehow ended with two different UTC files, in different locations, for the same address. Don't know how, don't know why. I know I haven't copied it manually. My guess is it's happened when I changed the chaindata directory using geth command line. Anyway, sometime ago I changed my password so they were different... Looking at the UTC file dates, I realized geth was updating one of them and the Wallet was checking the password against the other. So I copied the newest UTC file to the correct folder and started the node with --keystore. Everything is working again.
On the Wallet, go to Files -> Backup -> Accounts and it will open the folder were it expects the UTC file to be. Then check if there's no other UTC file for the same address somewhere (on Windows, the default is %APPDATA%\Ethereum).
Just make sure to do it right. If there are two files and you override the wrong one, you may never get your $$$ back. Good luck.

eaamgh on 14 May 2018

@eaamgh Where did you find that second UTC file?

VCBCN on 17 May 2018

@VCBCN, one of the files is in the directory pointed by the wallet. The second was in the default location (on Windows, %APPDATA%\Ethereum\keystore).

eaamgh on 17 May 2018

I have exactly the same topics. I am 101% sure the software did NOT ask me for an passwort at the initial setup. I did also try every possible passwords i ever used. No luck. Now the ETH is stuck in there. Because the software also not tell you at the begining the private key, there is no possibility to do any transaction with the ETH anymore. I can receive, but nothing sending out without passwort :(

ahonecker76 on 21 May 2018

@ ahonecker76, there's a possible workaround. It worked for me before I found out the UTC files issue. Download and install another wallet (I used Exodus) and do the transfer using it. It will ask your password. If you do have the wright one, it should work. Good luck.

eaamgh on 22 May 2018

any news ?

sebd-davra on 24 Jun 2018

👍1

yeah more explanations will be good because he is not very present on the net, could be a scam.

sebd-davra on 25 Jun 2018

Just an update for all, after giving up on any progress to be made here, I approached many reputed wallet recovery service providers, some of whom have been referenced many times on different issues.

Unfortunately after trying for weeks no one has had any luck and the account still seems locked. This is after me taking a screenshot of the password as I always do for crypto accounts.

I don't really have anything positive to add to this thread for now, I really look forward to hearing from the Devs if this issue has been recognized as an ongoing and actual problem by now..

pavneet09 on 12 Jul 2018

👍2

I don't really have anything positive to add to this thread for now, I really look forward to hearing from the Devs if this issue has been recognized as an ongoing and actual problem by now..

@marcgarreau and myself, aswell as other devs are doing all we can to get to the bottom of this. Of course it's a problem -- what we need to do is determine the cause ( or rather, causes -- because a lot of cases have different causes)

holiman on 12 Jul 2018

👍1

Mean while, hundreds of us are locked out from transferring Ethereum. I'm sitting on 250 Ethereum.

https://etherscan.io/address/0xb234035f7544463ce1e22bc553064684c513cd51

I'm told Ethereum doesn't know the cause. So build some test software and fix it. But I have a feeling these wallets are PERMANENTLY locked. What are you doing to address your customers/consumers? Have us create a new wallet, have Ethereum.org send us new Ethereum, and sign a notarized document saying we will not withdraw from the original account even if a bug is discovered. In essence, Ethereum will claim ownership on the bugged wallet.

I am able to prove that wallet is mine, as I am a PreSale buyer. I have receipt of purchase, and you guys have a copy. It may not help everyone, but probably 30% of us are presale buyers. We have tried to help diagnose the code, however, the original presale wallet site is not available, that code is gone. Therefor, there is a likleyhood we will never be able to find the bug that locked us out.

@holiman @marceloneil

anormore on 12 Jul 2018

👍1

It's a good idea to sign notarized document and recover our money if we can prove where the funds are come from. I can prove it too.

sebd-davra on 12 Jul 2018

but probably 30% of us are presale buyers

I'm not so sure about that. A lot of these wallets come from Mist/Geth interaction. Both the persons who sent me wallets had that case.

So build some test software and fix it

Oh there's been test software built, that I can promise.

holiman on 12 Jul 2018

@holiman Maybe you should organize a formal user complain registration. You know, before some one else does.

I don't doubt you have created test software, but you guys have to acknowledge that HUNDREDS of people are legitimately locked out. We acknowledge that an equal amount have simply forgotten their passwords. It's a dilemma we are all in together.

How about my proposal as seen above?

anormore on 12 Jul 2018

Regarding formal user complain registration -- the Mist team has created a google doc where people can enter details about their respective case, to better allow us to distinguish between different cases and possible similarities.

holiman on 12 Jul 2018

How about my proposal as seen above?

anormore on 12 Jul 2018

I'm a dev, trying to solve a technical problem. I am not a lawyer, and I really don't have anything to say regarding that proposal.

holiman on 12 Jul 2018

So please forward this to your manager, who may take it to the executive board of your company.

anormore on 12 Jul 2018

@anormore You are posting on a technical forum dedicated to source code, software development and related issues. Everyone here is a developer. We can try to help with technical issues, we cannot help with administrative/legal ones. If you wish to get in contact with non developers, please find the appropriate channels. We are not customer support.

karalabe on 12 Jul 2018

👎1

The only contact information listed for your company is....

GitHub.

https://ethereum.org/foundation @vbuterin

anormore on 12 Jul 2018

😄1

the support email is [email protected]

sebd-davra on 12 Jul 2018

I've emailed that, no reply.

anormore on 12 Jul 2018

I know... that is amazing...

sebd-davra on 12 Jul 2018

😄1

I'm in a similar situation.

I bought on the last day of the presale using one of my simple passwords that my friends know with a special character on the end (I think a '!', though it could have been a '?').

I've been trying to unlock this for a long time with no success and desperately so for the last few weeks. I had the presale wallet in a drawer on a CD. The drawer also contained a mnemonic (for the intermediate blockchain.info wallet?) and 59 hexadecimal characters written down. Were we given an opportunity to create an unencrypted backup of the seed? The latter may or may not be related.

[removed irrelevant personal info]

I'd appreciate if anyone had any leads or knew whether we were presented with an unencrypted version of the seed. if so, I would have left out the 5 hex chars to make it harder for a burglar to casually sweep the wallet while knowing that I could just decypt one of my other backups of the encrypted wallet.

Please message me or let me know where else this is being discussed.

uprising-bike on 14 Jul 2018

64 characters could be your private key. If so, you can try to brute-generate the corresponding addresses, which should be pretty simple.

holiman on 17 Jul 2018

Hi, I have been following this thread and other related issues as I am affected by this as well.

I created my account on Windows 10 using Mist 9.3 and then tried to unlock it on Linux once I had some funds (Using both geth and mist) several months later and I found the unpleasant surprise.

Could it be that default Windows 10 encoding, utf-16, is what Mist sends to geth to create the wallet, so that when you try to unlock it from another machine using utf-8 encoding it fails? Sounds really dumb to be true, but I am running out of ideas before starting to try to crack my own account ...

Lantero on 20 Aug 2018

👍2

As a side note, I use up to three different keyboards (US English, UK English and Spanish), but I don't use non-ascii characters, so that shouldn't be a problem. Am I right with this assumption? I have read that there were problems with other countries keyboards, but I guess that only applies to special characters, and not the keyboard layout itself.

I have tried typing the password with the three keyboards, just in case I missed the keyboard I was using and typed the wrong character on account setup.

Lantero on 20 Aug 2018

👍3

i use Mist 8.0.10 and 400.html....

artstr1 on 18 Sep 2018

Here's a geth change that adds an integrity check on the account creation step:
https://github.com/ethereum/go-ethereum/pull/17348

evertonfraga on 24 Sep 2018

And what about the accounts that have been damaged previously?

I have 250 Ethereum that are not accessible. Yet you acknowledge there are problems in generation, so much you must create integrity checks.

What happens to those of us locked out? Who did not have the luxury of an integrity check?

https://etherscan.io/address/0xb234035f7544463ce1e22bc553064684c513cd51

I propose that since I can prove that I purchased the Ethereum because I have my pre-sale receipts and so should Ethereum.org, and you can clearly see that the Ethereum is still there, you re-issue my Ethereum. I will sign a contract with Ethereum.org stating in the future event that this becomes a solved problem, it is considered the property of Ethereum.org.

What are your thoughts? I'm happy to start conversation with your legal team if needs be?

anormore on 4 Oct 2018

👍1

@anormore, I had the same issue. I still cannot send anything using the wallet. But if you know your password, a possible workaround is: download Exodus and point it to your keystore. After providing your password, you should be able to send ETH through Exodus. I'm not sure if other wallets would work as well, but Exodus worked for me. Good luck.

eaamgh on 5 Oct 2018

@anormore, I had the same issue. I still cannot send anything using the wallet. But if you know your password, a possible workaround is: download Exodus and point it to your keystore. After providing your password, you should be able to send ETH through Exodus. I'm not sure if other wallets would work as well, but Exodus worked for me. Good luck.

how? exodus import JSON?

artstr1 on 5 Oct 2018

download Exodus and point it to your keystore. After providing your password, you should be able to send ETH through Exodus. I'm not sure if other wallets would work as well, but Exodus worked for me.

This is the first I've ever heard of that. If that is indeed the case, it would be very interesting to investigate the (emptied) keystore file.

holiman on 5 Oct 2018

@anormore, I had the same issue. I still cannot send anything using the wallet. But if you know your password, a possible workaround is: download Exodus and point it to your keystore. After providing your password, you should be able to send ETH through Exodus. I'm not sure if other wallets would work as well, but Exodus worked for me. Good luck.

I only see the import of the private key, and how to make the import Keystore / JSON File?

artstr1 on 5 Oct 2018

Hi Everyone!

I've been offline re: Ether for a while, was stressing me out a bit too much to deal with properly.

I installed both Geth and Ethereum Wallet when I first started messing around with Ethereum. (Geth 1.8.1, and Ethereum Wallet 0.9.3)
I launched the application before the entire blockchain had synced, and the program crashed a bunch.
I couldn't sync easily on the regular mode, so deleted what blockchain I had already synced (not any keystore files) and successfully synced with the Light client.

I am certain; without a shadow of a doubt that I did not create a password, distinctly remember clicking skip on the password creation splash screen, thinking I could create a password at a later date.

Unfortunately I have sent ETH to this address, but at this point I am more or less out of hope of recovering my ETH so happy to send keystore files to trusted Devs.
Keystore file was created 21/6/17.

I'll post this info in the other active thread(s) to be safe.

Thanks again for your assistance, it truly is appreciated.

Best,

Jesse

JesseRye on 14 Nov 2018

@JesseRye before sending any files to anyone, did you try out the tool linked above https://github.com/holiman/go-ethereum/tree/recovery/cmd/recovereth ?

holiman on 14 Nov 2018

@JesseRye before sending any files to anyone, did you try out the tool linked above https://github.com/holiman/go-ethereum/tree/recovery/cmd/recovereth ?
@holiman How to use main.go? I do not understand what to do with it, help please :)

artstr1 on 14 Nov 2018

@holiman
I have the same question as artstr1 ... how do i use your link / support? I'm an absolute freshman.

https://github.com/holiman/go-ethereum/tree/recovery/cmd/recovereth

yesterday I created a second account in wallet and provided with password ...
can not again send a transaction also in the second account.

is it because I used both $ and & as special characters in the pass
08-32-2018_08 32 26-capturfiles
word?

Thanks for support

pachlito on 8 Dec 2018

@pachlito if you have a system where you can reproducibly create accounts that cannot be unlocked, that would be truly great if we can investigate a bit more!

Both those characters should be fine. Did you download a binary or build from source ? If you can build geth from source, I'd love to give you a diff which you can apply, that would print out to a log file the exact password byte-sequence that arrives into geth from mist, and which geth uses then uses to encrypt the wallet. I'd prefer doing that rather than send you a binary to execute, because it's better if you build from a source you trust with a diff that can be easily verified to be non-malicious.

Regarding recovereth, you would install geth go get github.com/ethereum/go-ethereum and then switch to my branch (within $GOHOME/src/github.com/ethereum/go-ethereum) do git remote add holiman https://github.com/holiman/go-ethereum.git and switch to that branch git fetch holiman; git checkout recovereth and then go into cmd/recovereth and do go build .

holiman on 11 Dec 2018

@pachlito if you have a system where you can reproducibly create accounts that cannot be unlocked, that would be truly great if we can investigate a bit more!

Both those characters should be fine. Did you download a binary or build from source ? If you can build geth from source, I'd love to give you a diff which you can apply, that would print out to a log file the exact password byte-sequence that arrives into geth from mist, and which geth uses then uses to encrypt the wallet. I'd prefer doing that rather than send you a binary to execute, because it's better if you build from a source you trust with a diff that can be easily verified to be non-malicious.

Regarding recovereth, you would install geth go get github.com/ethereum/go-ethereum and then switch to my branch (within $GOHOME/src/github.com/ethereum/go-ethereum) do git remote add holiman https://github.com/holiman/go-ethereum.git and switch to that branch git fetch holiman; git checkout recovereth and then go into cmd/recovereth and do go build .

Hallo holiman ...

i am very sorry, but that is too much for me ... am an absolute freshman ... and i have no linux ... just a mac.

pachlito

pachlito on 22 Dec 2018

@holiman I posted about how this can be reproduced a long time ago. IIn this thread:

https://github.com/ethereum/mist/issues/3513#issuecomment-361088481

anormore on 16 Jan 2019

@pachlito, если у вас есть система, в которой вы можете воспроизводимо создавать учетные записи, которые не могут быть разблокированы, было бы действительно здорово, если бы мы могли исследовать немного больше!

Оба эти персонажа должны быть в порядке. Вы загружали бинарный файл или сборку из исходного кода? Если вы можете собрать geth из исходного кода, я бы хотел предоставить вам diff, который вы можете применить, который распечатал бы в лог-файл точную последовательность байтов пароля, которая поступает в geth из mist, и которую использует geth, а затем использует для зашифровать кошелек. Я бы предпочел сделать это, а не посылать вам исполняемый файл, потому что лучше, если вы соберете источник, которому доверяете, с помощью diff, который легко проверить на отсутствие злонамеренного.

Что касается recovereth, вы должны установить geth go get github.com/ethereum/go-ethereumи затем переключиться на мою ветку (внутри $GOHOME/src/github.com/ethereum/go-ethereum) do git remote add holiman https://github.com/holiman/go-ethereum.gitи переключиться на эту ветку, git fetch holiman; git checkout recoverethа затем перейти в cmd/recoverethи делатьgo build .

How to do it on windows? python is installed if that

artstr1 on 17 Jan 2019

@anormore yes, the clrf is one possible case. It apparently doesn't do the trick for everyone, so I'm more curious about other cases where people are able to reproducably create accounts which cannot be unlocked.

holiman on 17 Jan 2019

@artstr1 the commands are pretty much the same for windows (git and go), but I don't have a windows environment to try it out on

holiman on 17 Jan 2019

I've managed to find a REALLY weird "issue" regarding one of my locked addresses.

Was originally created using myetherwallet.
1) was (copied and) uploaded to google drive as a "empty old wallet file" (date uploaded=19.5.16)
2) was copied into .../Roaming/Ethereum/keystore when trying GETH\MIST (date modified=18.9.16)
(reminder: This is the same wallet, address 0x9161ef...)

I've only encountered the problem when trying to unlock the version 2 (in geth) which didnt succeed, neither in MEW.
When trying to unlock version 1(from google drive) - in MEW - it worked.

What is actually going on?

When looking at both wallet file everything is the same BUT the salt, IV, ciphertext etc.

Version 1 (google drive, Opens properly with known password):

{"address":"9161ef..........","Crypto":{"cipher":"aes-128-ctr","ciphertext":"d83143598281fd38b5fc03dfc7a42d83d403c8f6b49ab3dc45e1e98eb3e25e1d","cipherparams":{"iv":"acf92f1b3922bbf09342a231a40515f2"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"85e52b522bc1521fda583f3988ff1b437df36bd42c20d554358c400de14207d0"},"mac":"facd0c3d4091198016c2e29a7e44f49e623f2698dd5c9772c22d90e9377d5a32"},"id":"2074fef6-c9a7-482c-83cb-6eda567a9d20","version":3}

Version 2 (Mist\Geth, does not work with any password)

{"address":"9161ef..........","Crypto":{"cipher":"aes-128-ctr","ciphertext":"fd1cfcc1bf0edf25faa9adb6b69eb9e1779dabc7ea34b92b64b757455513b5d6","cipherparams":{"iv":"19fe5df8d33eead42d99815e48aed2a4"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"e94e3fe4235e8a465100f488e4aa3a57f7cf7248e2888aca2b5abfff8f07abc4"},"mac":"81ea6348f8f93bf0192207c3ea34692f88a898dd85a5829dd951ec1069f6f282"},"id":"2074fef6-c9a7-482c-83cb-6eda567a9d20","version":3}

As you can see some data in the file is changed, but how? and why?
I'm pretty sure this is exactly what happened to me with the big funded locked wallet I've been trying to brute force for the last year or so.

Anyone encountered this?

teasider on 18 Mar 2019

https://github.com/ethereum/mist/issues/2411#issuecomment-480480905

My ETH is trapped as well. I don't recall ever making a pw for this useless wallet. I'm on OSX and initially downloaded in late 2017 iirc.

My questions are, what is the best brute force method, where is my keystore file, and can the attempts to crack this wallet originate from another lan connected device, or can the wallet be transferred to a Windows machine (isolated with substantially more power) and cracked there?

Lastly, have the ethereum developers acknowledged, or apologized, or resolved this horrible bug?

xander77a on 6 Apr 2019

hey @teasider , it's good to have an example of a wallet that was somehow "modified". Unfortunately we do not really know why and what software (geth or mist?) modified this .

It would also be a little bit more interesting if we knew the password (at least of the first one). Do you have that and can share it ? maybe also in private (for instance via PM on the hashcat.net forum if you are not comfortable to share it in public). I would be willing to give it a try to "crack" it or check if the password for the second one is kind of related to the first one by applying some mangling rules to the first password etc.
Do you remember entering a password in mist when importing the wallet ? The id is of course also the same and it's kind of normal that all those "fields" change if the password was changed or somehow imported/unlocked (and a new "salt" was assigned to that wallet).

I think if it is an empty wallet it shouldn't matter too much in sharing the password, but again do not share wallets in general with strangers especially if there is still balance in those addresses (there is furthermore another problem of privacy, because knowing the history of the address, you could do some analysis too.... I'm just making sure you and others know all the risks).

I think also @holiman is/was willing to have a look at some wallet files in private... so if you trust him more than me, I'm fine with that. For me it's just important that we investigate the problems reported in here in detail just to make sure that we do not miss anything. Thx

btw: it would be also interesting to know what the file name of those files is... did the UTC... file name change too ? My guess is that it did, but does that timestamp match with the modified date ?

philsmd on 4 May 2019

@philsmd & @teasider would one of you be able to point me toward an app or code which could work to brute force crack my wallet on an OS X, or from over a LAN with my windows?

xander77a on 5 May 2019

Well, I would of course recommend hashcat from hashcat.net (but I'm probably biased). To avoid false impressions I would also like to make very clear that hashcat is an "advanced" password recovery tool that takes for granted that the users are comfortable in using the command line (shell/cmd).
brute forcing is most of the time a really bad strategy (yes, I know people often call every password recovery attempt "brute force"), there are much more clever strategies/attacks/ideas like dictionary attacks with rules (-r) etc.
hashcat supports these hash types when it comes to ethereum wallets:
-m 16300 = Ethereum Pre-Sale Wallet, PBKDF2-HMAC-SHA256
-m 15600 = Ethereum Wallet, PBKDF2-HMAC-SHA256
-m 15700 = Ethereum Wallet, SCRYPT

a typical command looks something like this:

hashcat64.exe -m 15600 -a 0 -w 3 hash.txt dict.txt

where the file hash.txt needs to contain the output of

python ethereum2john.py UTC-..... > hash.txt

the file names at the beginning of the output line (of ethereum2john.py) need to be removed from the hash.txt file (see https://hashcat.net/wiki/example_hashes for example hashes, also ethereum hashes)

Again, there are other crackers too and if you are not comfortable enough to use the shell, there might also exist other approaches you could take (but it's very easy to learn how to use hashcat on the command line !). There are some GUI tools too, but most of them are not up-to-date or not that advanced (in my opinion). If you are not comfortable enough, you might also try to ask a trusted very good friend etc for help, but please, please, please do not get tricked/scammed by some online services etc.

btw: I forgot to mention that there are some blog post and of course hashcat forum post that explain how to recover ethereum wallet passwords with hashcat, like this one here: https://stealthsploit.com/2018/01/04/ethereum-wallet-cracking-pt-2-gpu-vs-cpu/ (for instance there is a really good hint for -m 15700 there that explains that with the newer scrypt based algos/wallets, it is often more clever to use your CPU - because scrypt was designed to make the GPU cracking harder and harder by using a lot of memory etc)

philsmd on 5 May 2019

👍2 ❤1

Thanks @philsmd for pinging me.
@teasider I would be very interested in studying your case closer, to try to determine what could have happened during the re-import.

Because the seeds are different, it's apparent that the file was not only _moved_, but actually imported and re-encrypted with new values.

I am interested in trying to figure out if any part of that process introduced a corruption. A while back, I made an custom binary to try permutating some of the values (https://github.com/holiman/go-ethereum/blob/recovery/cmd/recovereth/main.go ) .

If you'd be willing to submit the second file to me, along with the password, I could attempt to analyze it. I don't think I will need the first one. Before you do anything, however, you should empty the 0x9161ef... address, if you haven't already.

My pgp key is listed on https://geth.ethereum.org/downloads/ (Martin Holst Swende), so you can send info to me encrypted.

holiman on 5 May 2019

Thanks @philsmd very much. Time to get my feet wet. If I crack the wallet I'll send you 5% :)

One 'last for now' question: My etherium wallet is currently compiled/installed/existing on an IOS with 3.06 GHz Intel Core 2 Duo and ATI Radeon HD 4670 256 MB GPU. Clearly this isn't an optimum setup for number crunching, but I also have a Dell T7400 with 2 Intel Xeon processors and 32 GB Virtual memory. Can I somehow copy my wallet (with it's unknown pw) to this x64 based PC? Or is it permanently anchored to my iMac?

xander77a on 6 May 2019

I think you mean that you have a macOS system. (it's important to emphasize that it's not the best thing to crack with notebooks, because of throttling and cooling issues etc if it's the case that you are using a notebook)

Well, first of all it depends (as mentioned above) on the algorithm used by the wallet. The wallet file (json file starting with UTC--... in general), usually stored in these folders depending on your operating system https://github.com/ethereum/go-ethereum/wiki/Backup-&-restore, can be copied and used also with entirely different PCs and operating systems (it is usually not tied to any computer, operating system etc) and it also contains all the information.

Therefore, I would first start with copying that file (making backups too etc) and trying to run ethereum2john.py from the JohnTheRipper project (https://raw.githubusercontent.com/magnumripper/JohnTheRipper/bleeding-jumbo/run/ethereum2john.py , this is a python script, therefore you need to run it with python 2.7 for instance)... if you got the output of this, you should compare it to https://hashcat.net/wiki/example_hashes . The start of the hash (skipping/removing the file name and colon at the start), as you can see it is either $ethereum$w..., $ethereum$p..., $ethereum$s*...

if the output hash starts with $ethereum$s*, you need to use -m 15700 and therefore your CPUs might be faster (of course it depends also how fast your CPUs are and how many GPUs you have as alternative etc).

I would say that depending on the output of ethereum2john.py, you already know what could be best and you can confirm this also by doing some benchmarks.

hashcat64.exe -m 15700 -D 1 -b

if -D 1 (the CPU) is faster, you can adjust your cracking command like this:

hashcat64.exe -m 15700 -a 0 -D 1 -w 3 hash.txt dict.txt

I would say that 2 Xeon CPUs are better for -m 15700 (the scrypt algo).

btw: it's also possible to just copy the hashes to the different systems. The information contained is all hashcat needs (and again they are not tied to a specific system).

I would say that this should be enough info over here because we shouldn't hijack this thread, if you have some further questions about hashcat/cracking, you might just ask them over https://hashcat.net/forum etc and maybe link the thread here.

good luck cracking

philsmd on 6 May 2019

Спасибо @philsmd за пинг .
@teasider Мне было бы очень интересно изучить ваше дело поближе, чтобы попытаться определить, что могло произойти во время повторного импорта.

Поскольку семена отличаются, очевидно, что файл был не только _перемещен_ , но фактически импортирован и повторно зашифрован с новыми значениями.

Я заинтересован в том, чтобы попытаться выяснить, не привела ли какая-либо часть этого процесса к коррупции. Некоторое время назад я создал собственный двоичный файл, чтобы попытаться переставить некоторые значения ( https://github.com/holiman/go-ethereum/blob/recovery/cmd/recovereth/main.go ).

Если вы захотите отправить мне второй файл вместе с паролем, я могу попытаться проанализировать его. Я не думаю, что мне понадобится первый. Однако прежде чем что-то делать, вы должны очистить 0x9161ef...адрес, если вы этого еще не сделали.

Мой ключ pgp указан на https://geth.ethereum.org/downloads/ (Martin Holst Swende), поэтому вы можете отправить мне информацию в зашифрованном виде.

Good day. How to run a wallet verification script on windows. A person who is very far from it?
http://images.vfl.ru/ii/1557262920/d7d68bff/26455777.png

http://images.vfl.ru/ii/1557265486/40a40b49/26456025.png

Petachok13 on 6 May 2019

@holiman Я писал о том, как это можно воспроизвести давным-давно. В этой теме:

# 3513 (комментарий)

Can you say your mail? I want to clarify something with you

Petachok13 on 6 May 2019

Мне удалось найти ДЕЙСТВИТЕЛЬНО странную «проблему» относительно одного из моих заблокированных адресов.

Первоначально был создан с использованием myetherwallet.
1 ) был (скопирован и) загружен на google диск как «пустой старый файл кошелька» (дата загрузки = 19.5.16 )
2 ) был скопирован в ... / Roaming / Ethereum / хранилище ключей при попытке GETH \ MIST (дата изменения = 18.9.16 )
(напоминание: это тот же кошелек, адрес 0x9161ef ...)

Я только столкнулся с проблемой при попытке разблокировать версию 2 (в geth), которая не удалась, ни в MEW.
При попытке разблокировать версию 1 (с гугл диска) - в MEW - сработало.

Что на самом деле происходит?

При просмотре обоих файлов кошелька все одинаково, НО соль, IV, зашифрованный текст и т. Д.

Версия 1 (Google Drive, открывается правильно с известным паролем):

{"address":"9161ef..........","Crypto":{"cipher":"aes-128-ctr","ciphertext":"d83143598281fd38b5fc03dfc7a42d83d403c8f6b49ab3dc45e1e98eb3e25e1d","cipherparams":{"iv":"acf92f1b3922bbf09342a231a40515f2"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"85e52b522bc1521fda583f3988ff1b437df36bd42c20d554358c400de14207d0"},"mac":"facd0c3d4091198016c2e29a7e44f49e623f2698dd5c9772c22d90e9377d5a32"},"id":"2074fef6-c9a7-482c-83cb-6eda567a9d20","version":3}

Версия 2 (Mist \ Geth, не работает ни с одним паролем)

{"address":"9161ef..........","Crypto":{"cipher":"aes-128-ctr","ciphertext":"fd1cfcc1bf0edf25faa9adb6b69eb9e1779dabc7ea34b92b64b757455513b5d6","cipherparams":{"iv":"19fe5df8d33eead42d99815e48aed2a4"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"e94e3fe4235e8a465100f488e4aa3a57f7cf7248e2888aca2b5abfff8f07abc4"},"mac":"81ea6348f8f93bf0192207c3ea34692f88a898dd85a5829dd951ec1069f6f282"},"id":"2074fef6-c9a7-482c-83cb-6eda567a9d20","version":3}

Как видите, некоторые данные в файле изменены, но как? и почему?
Я почти уверен, что это именно то, что случилось со мной с большим финансируемым запертым кошельком, который я пытался перебить силой за последний год или около того.

Кто-нибудь сталкивался с этим?

https://github.com/ethereum/mist/issues/3513#issuecomment-356595758 Here the person had the same 2 key files per address. Strange
and https://github.com/ethereum/go-ethereum/issues/15633

Petachok13 on 8 May 2019

Any response on this?

https://github.com/ethereum/mist/issues/2411#issuecomment-501712886

pavneet09 on 18 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

artstr1 on 22 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

Petachok13 on 26 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

I actually have a locked eth wallet with the "@" character in it.. is there a known problem with that?

teasider on 26 Jun 2019

I actually have a locked eth wallet with the "@" character in it.. is there a known problem with that

I have the same problem. I read a lot of forums. There are people. who claimed that the correct password does not fit, but then it turned out that they used incorrect data. But there are also reports that the @ sign may cause a problem (but there is NO evidence). It was also written on this forum that the dot is sometimes ignored. A couple of days ago they wrote that the \ character also causes some problems. Have you tried typing typos in the password? how many characters do you have ???

Petachok13 on 26 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

I actually have a locked eth wallet with the "@" character in it.. is there a known problem with that?

and I myself discovered that if you use the console (cmd) and copy the password in English, but at this time the system language will be French, for example, then the French version of the password will be inserted into the console !!! although i'm copying English characters

Petachok13 on 26 Jun 2019

The \ could certainly be a problem as this is normally an escape symbol.
We had a web interface which then passed the password to the back to move it over IPC to the node. Those characters could have Ben problematic on boths ends.

The best way to test it is to to run a local node. Ideally a version from back then and try to unlock the account using the console. Then you’re the closest to the place where it’s decrypted.

Here you can try replacing special characters with its Unicode representation etc.

I hope that helps and the. All your fund will be recovered one day.

frozeman on 26 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

I actually have a locked eth wallet with the "@" character in it.. is there a known problem with that?

and I myself discovered that if you use the console (cmd) and copy the password in English, but at this time the system language will be French, for example, then the French version of the password will be inserted into the console !!! although i'm copying English characters

Do you mean the whole password will be different? or just the special character in french that replaces "@" on your keyboard?
I actually have another language installed on the computer..

teasider on 26 Jun 2019

Do you mean the whole password will be different? or just the special character in french that replaces "@" on your keyboard?
I actually have another language installed on the computer..

I say that I opened GET, copied the password into it - Qwerty, the keyboard language was NOT English. Despite the fact that I copied the English characters, the password was transferred to GET from the characters of the language that was currently the default on my system. I discovered this by creating accounts with a password that I already know. The characters @ and others are not related to the problem described above (but users claim that they used them, in the accounts they have lost access to)
Therefore, if your account was created via GET, then download it, run it and use the command

geth - unlock 0x **** password.
You may have tried this method, and it did not work simply because the copied password contained characters of the language, which at the moment was not the default language in Windows.
P.S. I do not have programs that automatically change characters, the keyboard layout, and so on. But in GET the password is NOT copied, but replaced by the characters of the layout that is currently used in Windows.
I tried 5 times, creating different accounts.
Windows 10

Petachok13 on 26 Jun 2019

Do you mean the whole password will be different? or just the special character in french that replaces "@" on your keyboard?
I actually have another language installed on the computer..
Also, if you know the password, have you tried to sort through all possible typos with brute force ???

Petachok13 on 26 Jun 2019

Do you mean the whole password will be different? or just the special character in french that replaces "@" on your keyboard?
I actually have another language installed on the computer..

I say that I opened GET, copied the password into it - Qwerty, the keyboard language was NOT English. Despite the fact that I copied the English characters, the password was transferred to GET from the characters of the language that was currently the default on my system. I discovered this by creating accounts with a password that I already know. The characters @ and others are not related to the problem described above (but users claim that they used them, in the accounts they have lost access to)
Therefore, if your account was created via GET, then download it, run it and use the command

geth - unlock 0x **** password.
You may have tried this method, and it did not work simply because the copied password contained characters of the language, which at the moment was not the default language in Windows.
P.S. I do not have programs that automatically change characters, the keyboard layout, and so on. But in GET the password is NOT copied, but replaced by the characters of the layout that is currently used in Windows.
I tried 5 times, creating different accounts.
Windows 10

So to try my known password while on the second language(not english) and copy+paste that?
unfortunately I already tried that and it didnt work (if that's what you meant)

Tried brute force as well

teasider on 26 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

No(

artstr1 on 27 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

No(

Tell your password, for the sake of interest and example. And did you beat brute force to the password?

Petachok13 on 27 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

No(

Tell your password, for the sake of interest and example. And did you beat brute force to the password?

Give your contacts mail or telegram

artstr1 on 27 Jun 2019

Since April 2016, I can’t log into my eth wallet, 1400 ETH is stuck, and mist and geth cannot be run that time!

what characters did you use in the password ???? maybe @ and what is the password language?

No(

Tell your password, for the sake of interest and example. And did you beat brute force to the password?

Give your contacts mail or telegram

[email protected]

Petachok13 on 28 Jun 2019

Is anybody successful in cracking their presale wallet ? Good amount of ETH is stuck in my account.

msrkp on 30 Jan 2020

No, Eth will not release their PreSale wallet web side generator, so we cannot debug it. For all we know it is intentional. Your Eth is GONE. Sorry. ~249.9 Eth :(

anormore on 30 Jan 2020

Man its very big amount ~15k ETH

msrkp on 30 Jan 2020

~15,000 ETH down the tubes bro. Sorry. 1% chance of recovery.

anormore on 30 Jan 2020

I don't know why they are not open sourcing the application which was used during presale.

msrkp on 30 Jan 2020

Don't know either. Go ahead and try to cause an alarm about it, but you'll be ignored. Tinfoil hat time bro.

anormore on 30 Jan 2020

If you dig in this thread, you will see I PROVE their account generation logic is able to be broken. Never acknowledged, never fixed. Not even in presale, in regular software.

anormore on 30 Jan 2020

Hey @evertonfraga ,

Is there any issue in open sourcing the pre sale web application? Can you please open source it so that we can generate password permutations according to the application. If a bug is really there we can try other password possibilities.

msrkp on 30 Jan 2020

I have long followed this thread because I am in a similar situation. 2000 ETH stuck in a presale wallet. Very disappointing overall. Participated in the Google Doc a while back; heard no follow up. @AndyNormore is, I think, appropriately abrasive given the number of people left in the lurch on this.

What is the reason behind not releasing the specs of the presale web app? Would doing so represent a threat to another Ethereum component, or do you guys just not have access to it any longer?

watcherwall on 30 Jan 2020

👍1

@watcherwall the web app was mentioned above: https://github.com/ethereum/mist/issues/3513#issuecomment-366007905

You can easily see the whole code at archive.org (and github, see link below) , I also explained some steps how to generate new wallets with that code above.
see https://web.archive.org/web/20140824160837/https://www.ethereum.org/
https://web.archive.org/web/20140824160929js_/https://www.ethereum.org/scripts/app.min.js

https://github.com/ethereum/www/tree/514c99663ebd5b276652ee1be377e560a092fbbf
etc

philsmd on 31 Jan 2020

@philsmd Thank you for the prompt response. I'll take a walk through this morning.

@anormore Your thoughts?

watcherwall on 31 Jan 2020

@watcherwall Ethereum is a bugged software and your coins are gone bro. If you look somewhere I above, I PROVE that you can generate busted wallets. Literally no response from @philsmd or acknowledgement. I gave up on this years ago.

anormore on 1 Feb 2020

Hey @philsmd ,

I've tried all the possibilities of the passwords I use, but I am not successful in that. Is it possible to crack the PBKDF2-HMAC-SHA256 with plain brute-force using printable characters and I am ready to spin up the vms in cloud with max computation power, I noticed we can reach max of 616.6 kH/s.

msrkp on 3 Feb 2020

@anormore I think this is a huge misunderstanding/mix-up/misconception: I have nothing to do with ethereum and these projects (geth or mist). I'm not a holder of eth, nor do I work for any of these foundations etc... I just got interested in this "problem" a while ago, because there were a LOT of users in the hashcat (the password cracker) forum and github issues that were very eager about hashcat developers to implement the "Ethereum algorithms" to recover their password because of the so-called "the Ethereum bug" (I remember that a lot and it got quite annoying/toxic, because hashcat has also nothing to do with this problem besides now supporting the algorithms).
I also think it makes no sense to blame any single person for a problem, because it doesn't make the problem magically disappear (nor make the problem any better etc). I think if you search for help you should probably look at the people that work for the ethereum foundation or help(ed) code the projects (like this list:https://github.com/orgs/ethereum/people etc)... but again, I wouldn't say anyone in that list is really the one that is the culprit for the problem/bug etc....

We also saw a lot of different problems and we also need to admit that when searching for related problems, there were also a lot of user-introduced problems/misunderstandings/misconceptions. Like users that didn't believe that they set any password, but later found out that they stored the password in a .txt file or password manager etc. There are so many different cases and probably a lot are PEBCAK (but I also believe, and kind of proofed with my discoveries above, that not every problem 100% is a user-only problem).

Maybe you mixed-up @philsmd with @PhilippLgh , but I think that's also not a good idea to blame somebody that maybe didn't really work with ethereum for a long time or this project especially. We should actually stick to some new findings/discoveries, instead of blaming a single person for a problem he/she isn't really responsible or at least is not her/his fault.

I don't feel like I need to acknowledge anything here, I don't work with ethereum, I have more or less nothing todo with this (except for implementing some hashcat cracking code for recovering ethereum passwords etc).
I think you (@anormore) are referring to this discovery (https://github.com/ethereum/mist/issues/3513#issuecomment-361088481 , btw: you should always link it otherwise it's very confusing what exactly you mean, because this is already a very long github issue thread and we had a lot of very interesting/nice discoveries so far)... The problem with this discovery is that it's probably quite rare that users try to input newlines within a one-line-only password field... normally such things are not even possible... as we found out above, the newline is just replaced by a space, so that is quite easy to test... but I think it's very, very rare that users try to paste multiple lines within a one-line password field.... that's quite a silly thing to do.
Nevertheless, of course users can/should try to append/prepend spaces to their password, just in case something like this really would unlock their wallet.

@51r1u5 unfortunately password cracking (normally) doesn't work like this... if the hash (password verifier/checksum) was generated/hashed with a very specific algorithm, you also need to use that algorithm to test if the password is correct. you can't just use raw SHA256 instead of highly iterated PBKDF2-HMAC-SHA256, just because it internally uses some kind of sha256... there are many other examples like this (md5crypt can't be cracked with just md5, just because the name includes a "md5" substring etc etc etc)... If the algorithm is different, you need to use that specific algorithm in general (of course in general and as a very, very, very, very rare excepetion there could be some cryptographic flaws within the algorithm itself, but that would be a scandal and of course nobody would use the "correct algorithm" if there exist a shortcut and of course as far as I know there is no way to use a different and/or faster password recovery attack than the one already implemented in a lot of password crackers).

philsmd on 3 Feb 2020

👍1

Please all, never ever ever send your account details to anyone on the
internet! This account offering recovery services was created 8 hours ago.
It is obviously a phishing scam.

There is absolutely zero link between "address generation" and your
encryption password.

On Sat, Sep 5, 2020, 07:17 watcherwall notifications@github.com wrote:

@pie5Aequ https://github.com/pie5Aequ Care to elaborate on the process
more so as to seem less scammy?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/mist/issues/3513#issuecomment-687545589, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA7UGPOZCOM2NT7KKPF6UDSEG3WFANCNFSM4EKTR4EA
.

karalabe on 5 Sep 2020

Mist: "Wrong Password" Issues

Description

Specific example links:

Related issues:

Most helpful comment

All 354 comments

COPY AND PASTE:

CANNOT LOGIN: I HAVE SUCCESSFULLY SCREWED UP MY PASSWORD!!!! HOORAY!

--------------------------------------------

Related issues