Age | Commit message (Collapse) | Author | Files | Lines |
|
I really want to rewrite that code to not use the very unperlish switch
statement, but the code is rather... complex and hairy. :(
|
|
As reported in https://vndb.org/t5868
|
|
Per https://vndb.org/t5864
|
|
|
|
|
|
This should result in a more natural tabbing order, skipping over any
links around the forms.
|
|
|
|
This ensures that, if an attacker evers gets read access to the
database, he will not be able to compromise any accounts. SHA-1 suffices
here, because the data being hashed is a random 20 byte string. The
search space is so damn large that you can't sanely brute force it, nor
are rainbow tables any use at that scale.
They're not salted. The password reset tokens are also hashed in the
database and do include salt, but I've no idea why we did that.
|
|
|
|
Completely disregard my comments regarding DoS in commit
6e0a0e1d00e11da9b4eab2163e19314f752b05b5 - successful logins aren't
throttled at all. The other reason for lowering this value is because
the API requires a login for each new TCP session, and it doesn't seem
like many (any?) applications keep the TCP session alive for very long.
Still, 65536 is more secure than the default of 16384.
|
|
|
|
I broke this when changing the column type of login_throttle.timeout.
|
|
I increased the N parameter to approximate about 500ms to generate the
hash. This is quite a paranoid setting for a website, but login attempts
are throttled so there's not much of a DoS factor. (Alright, password
changing feature isn't throttled so the DoS factor still exists. But
really, there's some pages with longer page generation times anyway.)
I did lower the size of the salt a bit (Crypt::ScryptKDF uses 256 bits
by default), because 64 bits of randomness should have low enough chance
of collision with only ~100k users (even with a million users,
seriously).
|
|
|
|
It doesn't make a whole lot to separate the hashed password and the salt
from each other, you need both to do anything with them, and from the
database perspective they're both completely opaque strings only usable
for direct comparison with other hashed strings.
This change is mostly as preparation for switching to a proper key
derivation function (sha256 isn't...) and to add support for longer
and/or binary salt.
Because the passwd field now needs to be interpreted in Perl, it's being
passed around as a binary string rather than a hex-encoded value.
API login is broken in this commit. I'll get to that.
|
|
I believe I didn't do this conversion earlier (back when I converted the
language types) because PostgreSQL didn't support dynamically adding new
values to an existing enum back then, and modifying an enum was a huge
pain. Recent versions do support this, so there's no reason to keep it
as a string.
...I just felt like adding some churn to the code base.
|
|
|
|
Easier to work with in custom queries.
|
|
This used to work fine before the AIR skin was added, because Angelic
Serenade used to be the first in the list.
|
|
|
|
The usercache maintenance cron is causing significant downtime each
month, so I've disabled it for now.
|
|
Suggested by Hinoe, quoting his reasoning:
In popularity rankings, change the normalization from
"sqrt(LowerVoteCount)" == "LowerVoteCount^0.5" to something that grows
somewhat more slowly.
Details: Natural logarithm itself (ln(LowerVoteCount+1)) is too slow;
at the current VN count (15403), it returns 9.64; however, sqrt(15402)
is just above 124.1, which I feel is already too high. After
experimenting with the exponents a bit, I decided that the best point
likely lies between 0.3, which returns a bit above 18.0, and 0.4,
which returns a bit above 47.3. Thus, I suggest that the new function
be LowerVoteCount^0.36788; the exponent is a 5-digit approximation of
e^-1, just because it's a nice number in the specified area and works
well, returning circa 34.7.
|
|
Apparently there are networks where a single visitor is assigned random
addresses in the /23 range for each request. This should fix the
login/registration form on such networks, and makes the login throttling
more robust (and easier to trigger for innocent people, but judging from
monitoring the throttle table, failed logins arent that common).
I wonder if /23 is enough, but we'll see.
|
|
The . match doesn't match "any byte". Without the /s flag, it doesn't
match newline characters.
|
|
|
|
|
|
|
|
formcode is strengthened by including the IP (-prefix) into the hash,
ensuring that the code can't be obtained by someone on a different
network.
I also removed the login form of every page. Felt kinda pointless.
|
|
|
|
|
|
|
|
|
|
In particular, don't run the tasks when I'm asleep. The SQL queries that
are run during maintenance can deadlock and cause multi to crash. I want
to be awake when that happens.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The stuff about promoting users to register isn't really necessary.
|
|
Fixes http://vndb.org/t5136
|
|
Shouldn't affect behaviour in any way, just get rid of the warnings.
|
|
http://vndb.org/t5121
|
|
|
|
|
|
|
|
|
|
|