Is the BIP39 extra word embedded-NUL resistant?

[NotATether]

Probably better to ask here cause last time I tried their Github it was just crickets.

NUL characters can be detected by checking the length of the string to see if it matches a counter that you keep incrementing until you hit a "\0" character (also known as NUL char). I know this is written in Python and all, but there may be a vulnerability when you restore such a seed phrase and password with other wallets. Then again there could always be a Python vulnerability that uses NULs, especially considering many people run their wallets on unpatched Pythons (i.e they don't update their packages every once in a while).

It is known that hackers often stuff malicious code at the end of an innocent-looking string after a NUL character under the assumption that the code will think it's the end of the string. So that's why I think it's important for Electrum to trim the password string before using it, in case it contains a payload to save the secret word to a file (I don't think it does that as of now).

[1715587880]

1715587880

[1715587880]

1715587880

[1715587880]

1715587880

[pooya87]

It is the user who sets the password so whatever they enter into the box is the own user's choice, and that is the only time it is written to disk. I don't see any way that this can be exploited to be honest.
It is the same for Electrum or any other wallets. But I agree, user interfaces must always be strict in my opinion about the input encoding they receive, I'd stick to UTF8 all the time and avoid even the emoji (Unicode) crap because there is no need for the extra complication when your UTF8 password can still be very strong.
Unfortunately the proposal itself is not strict about the input. It just normalizes them.

[PawGo]

But I agree, user interfaces must always be strict in my opinion about the input encoding they receive, I'd stick to UTF8 all the time and avoid even the emoji (Unicode) crap because there is no need for the extra complication when your UTF8 password can still be very strong.

The problem occurs when different versions of software would use different rules for normalization.
By the way: there are still webpages where user's password is converted into lowercase characters and then processed, because the assumed that it is more user-friendly (length and/or symbols are more important that remembering if given letter was upper- or lowercase).

[pooya87]

The problem occurs when different versions of software would use different rules for normalization.

As far as normalization goes, the rules are clear. It is using NFKD if my memory serves, the problem is that this is not enough restriction on inputs because it is basically accepting all Unicode characters which may not be possible to enter in another UI.

By the way: there are still webpages where user's password is converted into lowercase characters and then processed, because the assumed that it is more user-friendly (length and/or symbols are more important that remembering if given letter was upper- or lowercase).

Such webpages or any tool that does this should never be used because that is the dumbest way of modifying the input that is reducing the strength of the given password by a lot (roughly 40%).

[PawGo]

By the way: there are still webpages where user's password is converted into lowercase characters and then processed, because the assumed that it is more user-friendly (length and/or symbols are more important that remembering if given letter was upper- or lowercase).

Such webpages or any tool that does this should never be used because that is the dumbest way of modifying the input that is reducing the strength of the given password by a lot (roughly 40%).

https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

[pooya87]

https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

Just because it is "facebook" it doesn't mean they aren't doing something dumb. Otherwise there wouldn't have been so many news about facebook hacks where they leak user data.
But also you have to consider the target audience of Facebook. There is a lot of dumb people who don't realize the difference between upper and lower case in a password, specially those on phone where for example the first letter is capitalized automatically.

[PawGo]

https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

Just because it is "facebook" it doesn't mean they aren't doing something dumb. Otherwise there wouldn't have been so many news about facebook hacks where they leak user data.
But also you have to consider the target audience of Facebook. There is a lot of dumb people who don't realize the difference between upper and lower case in a password, specially those on phone where for example the first letter is capitalized automatically.

haha, no I did not paste link about facebook to justify it.
In fact, I would never think about that kind of "user-friendliness". You cannot imagine my surprise when I found it for the first time - I realized that I may log in into one of online shops with CAPS LOCK. I was really surprised, I had feeling like any password would work. Then I found out that some treat it is as a feature, not bug.
On the other hand, I think that now smartphones are smart enough to detect password field and disable autoCaps.

[pooya87]

On the other hand, I think that now smartphones are smart enough to detect password field and disable autoCaps.

I believe that is a UI thing not a Smart Phone thing. Basically your UI framework has to have a textbox that takes the password, open the virtual keyboard itself and set its properties like disabling the "shift" button at the start or showing the characters as * instead, etc.

[NotATether]

On the other hand, I think that now smartphones are smart enough to detect password field and disable autoCaps.

I believe that is a UI thing not a Smart Phone thing. Basically your UI framework has to have a textbox that takes the password, open the virtual keyboard itself and set its properties like disabling the "shift" button at the start or showing the characters as * instead, etc.

I still feel like password fields for wallets in particular should just make things simple and only process ASCII characters (and leave any bytes over 0x7f the way they are). It's a very bad idea to try to normalize anything that looks like UTF-8 as it's going to be converted to bytes for hashing anyway. Plus it could cause bytes to be different from what the user intended to type on a Unicode keyboard, making the same password not work in different software, particularly if the same wallet file format is used in multiple wallets, or if you try to restore the wallet on a different OS that uses a different default encoding.