WVE–002 Wasabi Case-Report

The horror of - SecurityException: Invalid Password.

Dávid Molnár
6 min readAug 11, 2019

The worst nightmare for a bitcoin user to have while sending BTC from his wallet reads “Security Exception: Invalid Password. So the BTC is in the wallet but it cannot be spent. Why? Because the private key, which is required to sign the transaction cannot be decrypted. Tough stuff and one user of ours find himself in this unpleasant situation.

Who is affected?

All conditions have to be met below to experience this problem. If you are included do not panic, your funds are safu. In the next release we will fix the problem and ensure compatibility.

  • OSX users
  • Users who have pasted their password (clipboard was used) when generating their wallet
  • Used special characters in the password (chars not included in ASCII)

In olden times…

Wasabi never tried to over-complicate features. You can do everything that is allowed by bitcoin standards. Wasabi does not try to narrow down the possibilities — basically you can do anything you want (but beware of the consequences). For example Wasabi does not counter-ask the Recovery Words — it is simply saying to write them down and also to write down your password. That’s it!

There are no “Enter Recovery Word number X” after you pressed the button.

You have just created a wallet with TWO clicks! It is easy and users can create wallets amazingly fast with it, but it also has a bottleneck — it is not foolproof. We did the same with passwords, try to break the typical user flow so you pay attention. This reduced the number of users who cannot access their BTC because of typos or forgotten password. But there are still many who forgot to the best practice of backing up your recovery words and passwords properly. Lucas provided a password finder software, and this fixed many problems with typos. Most of the password issues were solved with it.

Wasabi also tried to break the usual password workflow to ensure the focus of the users on the entered password.

Later Wasabi also added a double-check feature: when you try to load your wallet for the first time ever, you have to enter your password.

You cannot load your wallet until you entered the correct password at least once.

So here we are now:

Wasabi CTO (nopara73) also set up a Lost Password Strategy document to collect the issues and plans together.

Also Wasabi has just got a new user/technical manual on docs.wasabiwallet.io/using-wasabi/LostPassword.html which summarizes some of the strategies we use to protect users forgetting their passwords.

So what happened now?

None of the solutions helped on doorpost-refold — one of the users of Wasabi. He claimed:

Wallet inconsistently handles authentication with complex passwords.

And he wrote a detailed issue on github, he also followed the issue template, and PGP signed it, which is highly appreciated — thank you!

Brief description is that he generated a wallet, pass trough the first-time-verification but later tried to send BTC and got password error.

So we started to debug

The password used for debugging is:

w¾3AÍ-dCdï×¾M\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN”?:Ö@°&

Yes, that is a generated password. doorpost-refold also provided some very useful test-cases so the issue can be easily reproduced.

There were no errors on Windows and Linux, but I have found some strange behavior on OSX.

Password cut issue

I pasted the original password into the PasswordBox and some part of the text was missing when I checked it in the debugger.

The texts are in string format so backslash is the escape character.

Original:

w¾3AÍ-dCdï×¾M\\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN\”?:Ö@°&\n

Result:

w¾3AÍ-dCdï×¾M\\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯

The problem is in Avalonia (GUI engine of Wasabi). Clipboard handling has a lower layer which is a native interface written in objective C. This interface pass two parameters:

  • The data on clipboard as a byte array.
  • The length of the array.

UTF8 encoding using one byte per character for “everyday” characters. But there are some characters which uses two byte. If the password contains any of these characters Avalonia will cut the string. So instead of passing the size of the byte array, the size of the string passed. Here is the emulation of the error.

The fix — Password cut issue

It is fixed in Avalonia and will be merged. What about those users who generated the wallet with the bug and they live with that without knowing it? Well when the user enters the password it is tested with the entered password (with fixed clipboard). If it fails, Wasabi will also cut the string like the emulated bug and try with that. I have already started the implementation and it will be merged in the next week.

Dan Walmsley also suggested to notify the user, that the password is used in a compatibility mode. The reason to do that to let the user know the wallet was not generated with the expected one. If he wants to recover his wallet in another software (Electrum for example) or in Wasabi (fixed) it could not be done with the original password.

So users who will get the appropriate notification in Wasabi, should generate a new wallet and send their funds there. With this the compatibility to other wallets will be ensured.

First paste issue

After starting Wasabi the first read of the Clipboard is corrupted for some reason.

Original:

w¾3AÍ-dCdï×¾M\\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN\”?:Ö@°&\n

Result:

\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0�ÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯

We do not know the exact reason of this yet.

The fix — First paste issue

According to the tests, making a dummy read solves the problem. However we don’t know the reason and things can go wrong when using heuristic solutions — so it should be tested and investigated more.

Debugging obj-c inside .net issue

While investigating the two problems above Dan Walmsley noticed that the string in the debugger gets randomly corrupted. Luckily it turned out that only occurs in development environment. The reason is when holding the debugger (break) then the memory is being GCed by .net during.

The fix — Debugging obj-c inside .net issue

The string is copied so there is a reference to it this way it cannot be GC collected during the debug.

Debugging in OSX Visual Studio issue

I had a little confusion about backslashes during the debug. I am using Visual Studio for OSX. I put a breakpoint and checked the content of the password variable.

Original:

w¾3AÍ-dCdï×¾M\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN”?:Ö@°&

Result:

w¾3AÍ-dCdï×¾M\\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN\”?:Ö@°&

I noticed that the backslashes doubled or appeared in the string. So for example ‘\’ became ‘\\’ and “ became \”. Later I realized that is normal behavior, VS but escape characters to the places where it is required to be able to paste the string directly into the code. I was confused because of a VS bug. If you try to copy that string with right click / copy or CMD+C you will get the following test to the clipboard.

w¾3AÍ-dCdï×¾M\\\\Øò¹ãÔÕýÈÝÁÐ9oEp¨}r:SR¦·ßNó±¥*W!¢ê#ikÇå<ðtÇf·a\\\\]§,à±H7«®È4nèNmæo4.qØ-¾ûda¯ºíö¾,¥¢½\\\\¹õèKeÁìÍSÈ@r±ØÙ2[r©UQÞ¶xN\\\”?:Ö@°&

After the copy VS add escape characters again.

The fix — Debugging in OSX Visual Studio issue

Will report that problem to MS.

Notifying the users

If any modifications are done by Wasabi on the password it should be notified to the user. For example leading and trailing whitespaces are removed. The maximum length of password can be 150 chars.

Notifying the users about the change is important to be able to recover their wallet in any case. So they will know what password was used to generate the wallet.

What about the victim?

I posted some ideas to recover doorpost-refold wallet. Now that we know the reasons I am pretty sure that we will figure out his original password. Hope he is still there and able to do that, maybe already did.

Follow the happenings here.

--

--