Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)ST
Posts
0
Comments
640
Joined
2 yr. ago

  • You can not find that Option via the default Settings menu, you have to search for it or use the outdated control panel.

    Also Windows Home edition does not have this option.

    Edit: you can find it actually under Windows security.

    Still, it never pops up during installation.

  • You didn’t store the key anywhere but on that disk.

    Windows does not let you store the recovery key on an encrypted drive.

    The rest only means, we need to deal better with our data. All the above basically also applies when you HDD or SSD dies, which can happen any time.

    Backups is what you need, not an unencrypted drive.

  • All the input verification and processing of player locations is done on the server (at least in any respectable game), I can smell the fact that you haven't touched a single line of multiplayer code in your life from here

    Those checks can be buggy ofc or do not cover all possible exploitable behaviors. But when there are implemented correctly you can not circumvent them. Similar to a Login form, bugs excist.

    A youtuber named CodeOverflow made two great series about game exploitation.

    EDIT: things like physical hardware hacks are also near impossible to detect reliably except for stuff like blatant recoil hacks

    Not talking about that. And Client side anti cheat does also not help here.

  • Every. Single. Serverside anticheat ever implemented has been defeated with absolute ease.

    Even if true (it is not) this does not proof anything other the that to less resources are invested in it. Client side Anti Cheat is cheaper because you just simply buy that product and yiu have not fix your broken game code which bately runs smooth anyway.

    Client side Anti Cheat goes against basic IT-Security principles. Every single packet that is sent from the Client to the Server is User Input. It is not to be trusted. You have to validate it.

    When you login to your Online account the check if your password is correct does not happen on your Computer. It gets sent to the server and the server validates it.

  • You could use things like ray tracing to determine if one player can be seen by another on the serverside and only send packages when they can see.

    But to resource heavy to do that.

    Edit: Thinking about it, you simply have to render the whole map with all players server side and based on that determine which players can see each other and based on that send the information to the clients.

  • That is just wrong. For example, increased movement speed. Just check every couple of seconds if the movement that the player actually did is possible with the allowed parameters. Yes there can be bugs in that too, but not trivial to bypass when you validate every packages.

    It is resource intensive. But much more effective for things like movement then client side.

  • Its like the key in the Chip. But yes fundamentally it is like that. Now the Key needs to be stored somewhere safe like in your Phones secure enclave or in the case of your credit card a so called smart card (or sim card etc.)

  • The user does not need to understand it. A user does not understand https or hashing and salting. Still, every one of these is important these days for online security.

    I am not a huge fan of passkeys themself, especially when the secrets are held by big tech, but they promise better security and protection against command n attacks like phishing.

  • The difference is, that even if you enter the "password" on a phishing site, it is useless. Or when the server is compromised.

    The only way the passkey can get compromised, is when the device that holds it gets compromised.

    The same reason why hardware tokens for things like FIDO or U2F are recommended.

  • Passkeys are not passwords. When you authenticate using passkeys you will proof that you have the secret (passkey), but you will never reveal that secret to the service you are authentication against.

    So even if someone is able to steal that package containing the answer, that answer will not be valid a second time.

  • DoT also encrypts the request, so the ISP cannot spy on the Domain Name you have requested.

    And thanks to Https the ISP only sees the IP address which cannot in every case be resolved to a unique Domain, especially large sites that are hosted on service providers like Cloudflare, amazon etc etc

  • disable root login

    That does not do much in practice. When a user is compromised a simple alias put in the .bashrc can compromise the sudo password.

    Explicitly limit the user accounts that can login so that accidentally no test or service account with temporary credentials can login via ssh is the better recommendation.