Be careful, doing str(num) requires python to convert the binary representation it has num stored as to a decimal. (C)Python implements a quadratic time change of basis algorithm. This is slow enough that now for very large inputs python will raise "ValueError: Exceeds the limit (4300 digits) for integer string conversion"
To be exact, the hard limit is: you cannot delete more than 10% of your organization's accounts (capped at 200) via AWS Organization within a 30 day rolling window. You can always delete an account by going into it as the root user.
A number of assumptions seem to be missing from this article. Since the author is using the sigmoid function which is smooth, this argument actually only applies to approximating smooth functions. That is, you dont just need f to be continuous, you need all of its derivatives to exist and all be continuous. Also, since we are only able to have finitely many neurons, we need to be able to approximate f using step functions with definitely many pieces. So this argument can only be used if f is constant outside of a compact region.
Why does the function you are approximating need to be smooth? From the paper cited in the article, all you need is for f to be continuous on a compact subset of R^n.
That may have been the case in 2011 when that article was written, but I have just tested this now and my facebook does not accept my password with the case reversed by having the caps lock key on.
iirc, on mac capslock works like (caps OR shift) and on windows its (caps XOR shift), that is, on mac, with capslock on its always cap, but on windows its just a toggle.
Similarly there are many sites that allow you to log in using `your password` or `your password`.swapcase() (for example, Password123 or pASSWORD123). Automatically trying a variant only costs a single bit of entropy and can greatly reduce login issues
This doesn't always work by the way. When you venture outside of ASCII, it's quite often uppercase(lowercase(x)) ≠ uppercase(x) and/or the other way around.
The German letter ß gets uppercased to SS instead of ẞ by most libraries in a neutral/generic culture. ẞ on the other hand gets lowercased to ß.
This happens because there wasn't an official ẞ in German until recently but the uppercasing/lowercasing standard was already written for ß.
This doesn't particularly matter since there's a perfectly good fallback for people who do happen to have "exotic" passwords: just type the password in correctly. As long as your mapping is consistent, it's totally fine if the bit sequence you're hashing is linguistically nonsense, because you're never going to display that to the user.
What you don't normally want to do is normalize passwords before hashing and then only store the hash of the normalized string, because that's fragile to changes in your normalization algorithm, e.g. updating your Unicode data tables.
Most competent websites I know accept general UTF8 characters like emoji perfectly fine. There are a lot of crappier websites that don't even have proper unicode support for usernames or profile descriptions out there, though, so your mileage may vary.
As far as I know, there's nothing preventing a password field from containing any valid unicode string. The problem may be IME support or servers stuck in ASCII, but the textbox itself will just work.
Even surprisingly big names are surprisingly bad at this. Don't know recently, but Hotmail/Outlook used to have a rule of only using letters, numbers, and a handful of symbols, also limiting you to at most 16 characters or something. You couldn't even type a space!
They're not necessarily "bad" at it; there's a good chance they just want to make sure that the least competent of their users doesn't make a password that they have trouble with later. They don't care that security-conscious people get frustrated with it.
So I guess that could also be "bad," but not incompetent "bad" or Michael Jackson "bad."
This is much more excusable for email providers to prevent phishing. There are a ton of unicode points that indistinguishable from ascii letters. There are other security issues that can arise as well. Here is an example from spotify https://engineering.atspotify.com/2013/06/18/creative-userna...
I should have specified - this was (is?) for passwords, not usernames. I'm much more sympathetic to limited character sets in usernames, but I don't see much valid reason for doing so with passwords
Honestly, that stuff only proves that big name websites aren't necessarily competent. PayPal used to let you register an account with a password longer than the maximum password length used in the authentication code, for example, essentially allowing you to set a password you could never use with your account again. Being worth billions doesn't mean you've got all the basics down, it just means you've tricked many people into giving you their business.
Even good websites that will accept any valid password string will sometimes cut off the last part of a long password because their hashing algorithm throws that data away. Bcrypt, for example, supports a maximum input length between 50 and 72 bytes, depending on the library you use to hash your passwords. That's bytes, not characters!
More primitive systems used to have problems with non-alfanumerical passwords and once those algorithms have been unleashed upon the unsuspecting public, you need to support them in your login flow for years to come.
For what it’s worth the “big” company I work for stores usernames in MySQL. 15 years ago when the username column was created it was set for ASCII (or whatever legacy charset it was). Changing it to utf8 would be a royal pain in the ass, requiring all kinds of testing and crazy updates across the entire company.
So while we’d love to make it utf8, it is just too much work to justify doing over other things.
I should have noted - i was talking about their restrictions for passwords, not usernames. Since those are hashed before storage, i think there are far fewer excuses for such limitations.
What if the password includes İ. The swapcase would be i. And the again its swapcase would be İ. And swapcase of I is ı. And swapcase of ı is I. Right? Well, it should depend on what language you use. Or should it?
Also I think this was in Github; they ask uppercase and I enter Ğ and Github doesn't recognize it as uppercase letter.
For a long time, in some browsers/OSes there was a bug (or perhaps an archaic feature that was accidentally triggered) where the cursor in an input could get stuck and cause all new characters to be inserted to the left; I'm assuming it's related to that.
Notably this was a bug on the input for _setting_ your password, so if you think you've set Password123, you might have actually set 321drowassP, so even after fixing the bug it would still bite many users.
This is the first I've heard of it, and as a Linux user I feel like it's the kind of thing I'd either know about or experienced first-hand. What kind of system would do that? And "for a long time", like, you can't ever login anywhere, it's kind of obvious and breaking functionality badly, how can this exist for more than a single release if at all?
To be clear, it’s intermittent. Perhaps one in 500 times an input is focused, it exhibits this behavior.
I have experienced this so many times over my life with so many different hardware/software configurations, and I have to assume others have as well. It hasn’t happened in years but could explain why the “fix” described in the parent post was implemented.
That's great. However the method that you use to find the canonical representative [1] is quadratic (when the string has length N, there are N rotations and for each rotation you need to check N characters to determine whether this is earlier than the best on that you have found so far). For large strings you would probably want to switch to one of the linear minimal string rotation algorithms [2], for example Booth's Algorithm.
You hit the nail on the head. This is just the lexicographically minimal string rotation with a canonicalization step. I have actually had this on my to-do list for a while. The truth is that the data set I'm applying this to is small (though I'm doing my best to change that by discovering new viroid-like agents) so the optimization has yet to become pressing. At some point, I'd like to spin this script out into a standalone tool but I'm not sure the demand is there yet.
