• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle

  • Because they are unilaterally removing benefits that people have already paid for, and are explicitly stating that they will provide no refunds.

    If you paid for a year of premium, a good chunk of the benefit has been the coins to buy awards.

    After they get rid of both coins and awards, well, you have still paid for premium in advance, but it is now worth a fair bit less to some people.

    Also bad, but more arguably in regards to the law, they are choosing to remove all past awards on posts and comments.

    Which means that people who have bought coins (or premium to get coins) are having all of that undone, again, without any possibility of refund.

    Arguably, this is much more problematic for people who had purchased coins, but who had not used them all before the announcement. Because that’s taking the money, and then simply choosing not to provide the service that was paid for, while simultaneously stating that there will be no refunds.

    You could try to argue that, well, they can use those coins up until they turn buying awards off… Except, well, one of the nice things about awards is that they last as long as the post or comment does.

    This is… Problematic.

    Extremely problematic.


  • That’s like saying that only using high security locks with various security pins in them to protect your house is a bad idea, and you should throw in some secured with padlocks too just to change things up.

    And if some of them are shitty masterlocks, well, you’re changing things up.

    That’s really not how security works.

    Yes, pass phrases can have large amounts of entropy attached. But unless you are picking your pass phrases truly randomly, with a large dictionary, and using unique pass phrases per site, and the sites are not silently truncating the password input (such as bcrypt which truncates to 72 bytes), you are not actually getting that large amount of entropy.

    Where as a 16 character password that randomly uses the ASCII printable range, excluding spaces, gives you 93^16 possible combinations. That’s 31313180170800116587336013460801 passwords.

    Or, very roughly, 104.6 bits of entropy. (104.6265409777285022441578006899739 bits of entropy if you want to be downright absurd about it.)

    Knowing that you’re doing that simply doesn’t help the attacker in any meaningful way.

    Bumping that to 20 characters gives you over 130 bits of entropy, or 2342388736625917052139104541473924426001 possible combinations.

    This is quite simply not a viable attack surface.

    Where as saying ‘use pass phrases for some things’ means that it is quite likely that some of your pass phrases are going to be much less secure than this.

    But let’s give the same numbers for properly generated random passphrases.

    The xkcdpass utility can help us here.

    Even picking entirely randomly, out of a large word list of 7227 words, a 6 word pass phrase only gives roughly 76 bits of entropy.

    Going up to 8 words gives us roughly 102 bits of entropy, that helps a ton… Except that some of those passphrases are going to be longer than 72 bytes. So you’re almost certainly losing bits of entropy.

    That best case still gives you fewer bits of entropy than a 20 character randomly generated password. Unless you’re trying to memorize your password, there are no benefits to alternating between randomly generated passwords with good generation settings and passphrases.

    And if you’re trying to memorize your passwords, you are definitely doing it wrong.


  • The advice to always use a unique password per site is an excellent one.

    The why is multifaceted, and some of them are moderately complex.

    First off, not every site is going to be storing your password in a good a secure manner.

    In an ideal world, every site on the planet would be hashing it with something like bcrypt with a fairly aggressive cost setting, and good salts.

    And they would have a way to automatically rehash your password on login in the event that the password hashing settings change. (Almost everyone misses this one.)

    In practice… It could be stored in plain text. It could be hashed with classic crypt(), or with md5 or sha1 with no salt. There are so many ways to get it wrong.

    On the rehashing one, they could have picked something that was best practices at the time, you setup your account, and then two years later, best practices have changed, it turns out that there was a way to attack the previous way, so they change how they do it… And that’s great for everyone who changes their password or sets up a new account after that change, but everyone who did it before that change? Well, those passwords are just sitting there hashed by the old method indefinitely.

    Or someone could compromise the site, and grab every password everyone enters.

    Or you could fall prey to a phishing attack, and type your login to what looks exactly like the site in question, but is infact a common typo of the real domain.

    Again, there are a lot of ways for the password used on a site to get compromised. Many of those ways are entirely out of your control. It is standard practice for attackers to attempt to use that password and username / email on other services when this happens, just so that they can see what else they can get into.

    Don’t let that work.