Bitcoin Forum

Lately several users have created apparently blank usernames (on several encodings, not all of them) using the character
URL-encoded version:

This character can also be used to impersonate another user by appending it at the end (or other position) which can cause security problems. It should be explicitly forbidden to use.

To test it I created this fake account of myself:
https://bitcointalk.org/index.php?action=profile;u=555622

In the meanwhile be extremely careful when trading with newbies with accounts matching older members.

I've reported this bug like 2 years ago.

It's a feature >:(

Ecua���Mobi is always on something unique..
anyways I had already reported such cases in 2014 when i joined here..
even if you use few characters that are not supported by SMF , it will work the same as you wrote in op.

I didn't realize about this until today, I guess I'm late then but it's worth pushing the subject. Only basic characters that are guaranteed to be visible on every charset should be allowed for usernames.
I noted this character is completely invisible in my Chrome but I can see it in the titlebar of Firefox (although not on the page itself). It surely depends on the browser, language and specific used charset.

Damn, that's why I see the last 3 names (that automatically added) on my trust list:
https://i.imgur.com/oXoouhN.png

Hmm, yeah it seems at the moment that tweaking my trust list causes a bunch of these to appear:
https://i.imgur.com/mZV4JfW.png

Yes the same happens here :/ If I enter just 'DefaultTrust' and hit save I get this:
https://i.imgur.com/hybdSDI.png


Did you get those 3 last lines automatically?
Besides that did you exclude my (real) account manually or was it added automatically too?

I've added your account manually and the last 3 lines were auto added.
(Ps: I don't intend to distrust you, it was about something else :) )

I was asking because if I manually type this:
https://i.imgur.com/PQFuNAq.png

I automatically get this:
https://i.imgur.com/PwHjFbS.png

My main account is excluded and those blank accounts are included! So it's concerning if the first can appear automatically and the second is one 'Update' click away. Although maybe you got my fake account just because you had added my real account before anyway. Can an admin check into this?

just tried clicking update with only DT on my trust list.
the blank accounts get excluded automatically (can't even remove it) while the copycat accounts are not. added Ecuamobi and the copycat Ecuamobi also appeared.

the auto-update is kind of weird because both admins are not online at since hours ago.

Confirmed same here when I checked this morning, but now I don't see the same behavior.  Was some fix implemented?  I also noticed that poster number 3 in this thread went from a username of the empty string to a username of "bad_char1".

I sent a PM to theymos and BadBear with a list of accounts with that character asking them to rename (or delete) those accounts. Maybe they did because of that or realized it by themselves. I also noticed those accounts were temporarily under theymos' trust list so I guess he was checking it. My fake account was also renamed to bad_char13. It seems to be working fine now.

Got it.  That also explains why they were showing up by default for a moment there.  Thanks Ecua for filling me in (and thanks admins for fixing it).

Interesting bug. When using the utf8_unicode_* collation, MySQL treats invalid UTF-8 characters (like the X'C29D' string used here) as being equal to an empty string, even in the middle of other strings. Normally this isn't such a big deal, but in certain queries it's a major problem. In particular, this is really really bad if you're using the text as some sort of ID and the ID column is not constrained to be unique (as is the case with SMF's memberName column for some reason).

Those weird users were being added to your list because an SQL query was adding all users who matched memberName in ('') or in EcuaMobi's case memberName in ('Quickseller', ...), and this matched multiple unintended users due to that empty-string confusion. There are security implications here. AFAICT, some serious (but not critical) mischief could've been done by impersonating privileged users in certain cases. I bet there are a lot of sites out there that have more serious vulnerabilities due to this sort of thing. And I never even considered collation as a source of these issues -- it's not something I've given more than a passing glance at previously. This looks like a pretty serious flaw in SQL and/or MySQL which should be publicized more IMO. It's too difficult to reason about correctness here.

- I cleared those users from everyone's trust lists and renamed them. Some similar users probably still exist in the DB, but I don't see the need to search them out.
- I revised all of the database's collation rules to settings which should work as intended. This required locking tables for extended periods of time, which is what caused the other weirdness over the last few hours.
- I made it so you can't use names containing invalid UTF-8 strings or control characters.