Consti

Basically anything low level. When you need a byte, you also don’t use a int, you use a uint8_t (reminder that char is actually not defined to be signed or unsigned, “Plain char may be signed or unsigned; this depends on the compiler, the machine in use, and its operating system”). Any time you need to interact with another system, like hardware or networking, it is incredibly important to know how many bits the other side uses to avoid mismatching.

For purely the size of an int, the most famous example is the Ariane 5 Spaceship Launch, there an integer overflow crashed the space ship. OWASP (the Open Worldwide Application Security Project) lists integer overflows as a security concern, though not ranked very highly, since it only causes problems when combined with buffer accesses (using user input with some arithmetic operation that may overflow into unexpected ranges).

Very often you need to choose a type based on the data it needs to hold. If you know you’ll need to store numbers of a certain size, use an integer type that can actually hold it, don’t make it dependent on a platform definition. Always using int can lead to really insidious bugs where a function may work on one platform and not on another due to overfloe

Got a bit too much into BASIC?

Ternary, and inline switch (match expressions), as found in functional languages

Of course it won’t do anything, you need to update (refresh the index) before you upgrade (download and install updates), silly you

I would be very interested in that book. My university did not provide explicit book sources, so I can’t tell you what that is based on, but here are the relevant slides (from page 9). Server-side hashing is so ubiquitous as the standard that e.g. OWASP cheat sheet doesn’t even explicitly say it, but their recommendations hint at it.

A quick google search on the topic revealed others with the same opinion: stackoverflow stackoverflow. The second link (accepted answer in the same thread) argues that with a protocol around it, it can make sense, but never in the situation described here. There needs to be a meaningful computation on the server’s side, otherwise the described scenario can happen.

It’s a bit difficult to find papers on that because server-side hashing is standard, but here, for example, is a paper that explores client-side hashing (see the introduction with a reference to server-side hashing and section 2): Client Password Hashing paper. Very interesting is also section 3.4. Similar paper: Client-side hashing for efficient typo-tolerant password checkers. Essentially, both suggest that to avoid the described attack, both server-side and client-side hashing is necessary (but the server-side hash can be weaker), see “Authentication attacks after leaks”. Neither paper describes how the client-side hashing is done on the Chinese websites they mention.

You’ll also find that many frameworks (e.g. ASP.NET, Laravel) implement server-side hashing.

My conclusion from the little research I did after your prompt is that client-side hashing can work, but it’s dangerous if done incorrectly (e.g. when done as suggested above), due to the scenario I described.

Not necessarily. If it’s implemented well, the frontend will just show a “success” message, but the email sent will be different. This way, the owner of the account will know if they already have an account, or if it wasn’t them, that someone else tried to use their email. Meanwhile the bad actor won’t know anything new.

No, it is not. If the server accepts the hash from an untrusted source (the client), then that’s equivalent to not using hashes at all. The reason why we hash is so a database leak does not allow malicious actors to login directly. If the server accepts a hash, that means it only does hash_from_client == hash_from_db, meaning that’s the same as doing password_from_client == password_from_db in terms of security. This is because the client can just send the hash from the DB, the user does not actually need to know the password, hence your proposal is equivalent to not using hashes at all in terms of security.

The point of sending hashes info from the client is that each site uses a different key, even if publicly available. This means that leaked login data cannot be compared or matched across different leaks.

That is for keyed hash functions, which is not typically done for passwords (but peppers are sometimes used, which helps similarly). This does not prevent the above scenario, though, because the leaked hash can still be used on that site. Sending hashes is a bad idea, the hash should always be computed in a trusted environment to ensure the user actually knows the password.

The client doesn’t hash. The client needs to send the plain text. Otherwise, that’s a security problem; the server needs to confirm the user knows the actual password, so the server needs to compute the hash and compare. If the client sent the hash, then there was no reason to compute hashes in the first place, because the attacker can just send the leaked hash (the reason to hash it is to avoid that the leak can be used to log in directly).

Why the fuck would the client confirm the hashes? Don’t trust the client. The server handles the login; an attacker can just write a lying client “yeah sure I know this guy, it’s hitmyspot, now let me in”.

The only reason we store passwords in hashed form is to prevent damage from leaks. How would storing it twice make login more secure? The client sends both the email and the password in plaintext, everything else is on the server’s side. The client does not care or know how the data is stored (or if it is stored at all). So storing it twice does nothing except waste disk space.

The only thing that needs to be encrypted or hashed is the password.

But telling that an email is already in use is leaking information. A bad actor can use this to figure out if you are using a particular service, or alternatively try random email addresses and check if they belong to a real user. This is why it’s usually encouraged to just say “invalid combination of username/email and password”, instead of specifying which is incorrect.

Did you really mirror the image part to repost this? Even the watermark is flipped

I actually had to test this with my hardware, Win11 is atrocious. I don’t have exact numbers, but Win11 uses so much more RAM for itself that it’s really noticeable how it just gets slower so much faster when I open stuff.

I was programming in assembly for ARM (some cortex chip) and I kid you not the C program we were integrating with required 255, with just 1 it read it as false

Latvia is partly involved, yes, but it’s also part Russian and recently moved to Singapore. You may find the history section on Wikipedia interesting; it also lists the russian part-ownership as reason for many users leaving OnlyOffice (and I’ve seen quite a few posts on that at the time).

As for the open-source part, I stand corrected, thank you

From what I can tell, OnlyOffice has the best compatibility and the nicest UI (similar to MS office), same as with the regular applications. NextCloud Office is based on LibreOffice (officially Collabora, which is their name for the web product), so again same as the regular applications you’ll have some compatibility issues. That said, if you don’t need compatibility with existing documents or only documents made with LibreOffice, either is fine.

One concern many have is that OnlyOffice is closed source (edit: my bad, it’s been open-source for a long time) and russian based (edit: partially russian, see Wikipedia), while LibreOffice is open source.

If you need finer control than recursive chmod (see other replies), you can also use find to match precisely which files/folders you want and use the -exec parameter to run chmod on those

The main reason for Ubuntu against Debian is the packages. For Ubuntu, they’re much newer, and with PPAs (launchpad.net), you can often get more and/or newer packages built by other users. For debian, good luck, you’re stuck with old packages (which is the intent of Debian stable, but not nice as a user, that’s for server)

Same logo as on the left picture (bottom right corner) but rotated to align with the finger