all 36 comments

sorted by: hot top controversial new old
[–] 85 points 6 months ago (16 children)

Passwords should be paired with a second factor, preferably biometric, said Gunner, because it’s the most difficult for hackers to bypass.

I think this is a pretty naive risk analysis. Hackers cracking my lemmy password is the least of my concerns. Having my biometric data leaked is one of my highest ones.

  • source
  • hideshow 16 child comments
  • [–] 30 points 6 months ago (4 children)

    I think Gunner means a biometrically unlocked second factor like a Yubikey or a smartphone's user attestation. Given how badly written the entire article is, I wouldn't be confused if that's what he originally said before they condensed his statement beyond comprehension.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 8 points 6 months ago (3 children)

    Yubikeys are still not biometric unless you're buying the super-super expensive one. They are just very secure MFA. (in that it's extremely hard to read the secrets from them even with physical access)

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 6 months ago (2 children)

    Don't they just spit out the long password when you press them, I'd figure it would be easy to just plug it into your phone and copy the output if you had physical access

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 6 months ago

    That is but one method of Yubikey. They also support cryptographic passkeys and can store TOTP secrets as well as PGP crypto keys.

    The "touch key random key" is a OTP code that can be used for legacy software, Passkey and/or other functions are more valuable to me. Can read more about OTP security here.

  • source
  • parent
  • [–] 2 points 6 months ago

    It's OTP. Once a code has been seen, all the previous ones no longer work. There's no point in copying.

    There's a second slot that can be used for static passwords. But don't, obviously.

  • source
  • parent
  • [–] 5 points 6 months ago (9 children)

    Wouldn't biometric data be sensor/implementation specific. I doubt the fingerprint data stored on an iPhone is the same as the one stored on an Xperia.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 8 points 6 months ago (5 children)

    Your fingerprint is your fingerprint. If its possible to extract the raw data, then that can be reconstructed into your fingerprint...

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 6 months ago (2 children)

    in the early 2000s when fingerprint readers started getting popular, my coworker and I decided to test them...

    super glue fumes, printer toner and scotch tape. that's all that was ever needed to bypass the reader once you could isolate a good spot where someones finger left a good mark. like from drinking glass or a door knob

    I'm not sure if I'd ever trust a fingerprint to fully be a secure passkey

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 6 months ago

    That's the thing - it's not possible. The fingerprint is only ever stored within the fingerprint module, with no method for retrieval. The only thing the phone sees is "did this person scan a matching fingerprint or not?"

  • source
  • parent
  • [–] 3 points 6 months ago (2 children)

    I don't think that means it cannot be leaked

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 6 months ago (1 child)

    Yeah, but what would you do with it? Can you convert the bytes to work on any other sensor the victim may also use their fingerprint? Never looked into the real implementation details of the fingerprint hardware.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 78 points 6 months ago* (last edited 6 months ago) (1 child)

    So Kaspersky found out that MD5 passwords are unsafe. That's literally 20 year old news. Actually, Kaspersky found out that brute-forcing MD5 on consumer-grade hardware has become slightly faster than two years ago, which makes me wonder if Captain Obvious's secret identity is that of a Kaspersky cybersecurity expert.

    El Reg concludes from this that we should ditch passwords, which they back up with the opinion of a second expert. This expert immediately tells them they're wrong, that passwords are perfectly fine if used with MFA, and that a lack of public knowledge about basic cybersecurity is the real issue. They somehow treat this as him agreeing with them.

    Actual technological alternatives to traditional password use (such as passkeys or password managers with per-site passwords) are mentioned only as an aside or not at all. It never occurred to El Reg or Kaspersky to mention that MD5 has been considered obsolete since the days of Internet Explorer 7 and that more secure hashes like bcrypt have been around since the late 90s. For that matter, the Kaspersky source talks about rainbow tables without using the word "salt" even once.

    Finally they conclude with a call to action to "improve that user security stack", arguing that passwords are inherently unsafe due to their "complex requirements and hashed storage". That's so deep into la-la land that I'm not even sure what it is they're trying to say or who they're even talking to.

    That's an amazingly badly written article.

    What impresses me the most is that the Kaspersky article they're talking about is just as asinine as El Reg's confused stammering. The most sense I can make out of it is that they're making a bad faith argument ("we can brute-force MD5'd passwords with a 5090 so you should use MFA") because they're trying to get nontechnical people to do the right thing and hope they can scare them into compliance if they bullshit hard enough.

    Edit: I just noticed how often Kaspersky's article refers to the own password manager they sell. So their bad faith argument is really just in service of an ad that happens to contain some decent security advice.

  • source
  • hideshow 1 child comment
  • [–] 32 points 6 months ago (2 children)

    A simple workaround is to just use one of the other 40%.

  • source
  • hideshow 2 child comments
  • [–] 18 points 6 months ago (2 children)

    I mean, yeah. MD5 blows for this. It's not like programs recommend you keep an MD5 hash of people's passwords on disk or in environment variables, right Perforce?

  • source
  • hideshow 2 child comments
  • [–] 13 points 6 months ago

    The amount of websites I'm forced to create accounts on for various mandatory crap that insist on a short password (12-16 characters seems common) is embarrassing, and causing a large part of this issue.

  • source
  • [–] 12 points 6 months ago (2 children)

    Wow this article is kinda shit. MD5 was on the chopping block for password hashing over 20 years ago. It's so seriously broken that if someone is using it they deserve to get bludgeoned to death with a Model M keyboard. We have purpose built solutions just for password hashing.

    The only thing the fine bad article sorta got right was two factor. I say kinda because biometrics (something you are) isn't that great of a second factor. Mainly because you can't change it. Also, it's a fuzzy match rather than a hard match. It can be acceptable to use locally and where all the information stays locally AND there is sufficient hardware based security where said biometrics isn't going to get off the device.

    Finally, there was no mention of any kind of physical token based factor (something you have). Which pairs well with password, passphrase, or any other "something you know" factor.

  • source
  • hideshow 2 child comments
  • [–] 3 points 6 months ago (1 child)

    I still used MD5 hashing in the apps I work on.

    Just not for passwords.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 6 months ago*

    If you need hashing for non-security applications, that's fine, but I'd still suggest SHA-1 or -25 or even just CRC instead, as that's something modern (as in less than 15 years old) CPUs can usually do directly in Hardware.

  • source
  • parent
  • [–] 8 points 6 months ago

    Hasn't md5 been cracked for like 2 decades? Now if they could Crack like aes-256 in under an hour this would be a different conversation.

  • source
  • [–] 8 points 6 months ago

    A private security company ask people to give valuable biometric data. No reason to trust what they said, furthermore without step to reproduce.

    However from this article :

    The professor noted that, in many cases, users aren’t told how to create a good modern password, and in other cases, sites simply don’t enforce adequate password requirements to make passwords secure, to the degree that they can be made so.

    Maybe a shall do more crypto-party instead of send our passwords online, giving our phone numbers or biometrics.

  • source
  • [–] 7 points 6 months ago* (1 child)

    In the past, I was a user of bad passwords. Anything I didn't care about I'd just pick an easy one. Probably 60% of the passwords I created, I did not care at all about and would've been perfectly okay with someone cracking them if they'd wanted to.

    I have since changed my ways and use good passwords now. I want nothing to do with biometric data collection and hope that it never becomes normal. Everyone without some kind of brain problems that prevent it should create and remember one good password — the one for their password manager.

  • source
  • hideshow 1 child comment
  • [–] 4 points 6 months ago

    I'd use at least one more: The one that unlocks your device shouldn't be the one that unlocks your password manager. Other than that, yes. Use a password manager, let it generate per-service passwords for you, and make sure you have a backup plan.

    For example, I use a KeePass database shared across my devices via a self-hosted NextCloud. Each of my devices plus the server effectively holds a backup copy so I'd have to lose all of my devices plus the server before my password database becomes inaccessible. Since the server lives in a datacenter it also serves as a remote backup.

    If your password manager is SaaS, you might want to investigate how to protect yourself from scenarios like the service being down or you losing access to the account.

  • source
  • parent
  • [–] 5 points 6 months ago

    An hour? Wtf? I swear that 5+years ago I saw a tool that would trivially modify any file by appending MD5-sum-length bytes to match any desired MD5, within a fraction of a second.

  • source
  • [–] 4 points 6 months ago (1 child)
  • [–] 4 points 6 months ago*

    I'm not sure it matters. If not it's rainbow table time but they did use a very high end graphics card to test so it's functionally equivalent to salting (except for the tiny extra compute to concatenate the strings before hashing).

    I feel like it was just a marketing exercise to show how shit MD5 is.

  • source
  • parent
  • 21 comments in c/privacy@lemmy.dbzer0.com view that post
    [–] 64 points 6 months ago

    MD5 hashes have been crackable on consumer hardware for like 20 years.

  • source
  • [–] 31 points 6 months ago (2 children)

    That's why my bank does not hash the password. They directly send me plain text password over SMS. It is secure that way.

  • source
  • hideshow 2 child comments
  • [–] 20 points 6 months ago* (5 children)

    That's why they need a little bit of seasoning. Some salt would do the trick. At least it would help with a dictionary/rainbow table based attack anyway

  • source
  • hideshow 5 child comments
  • [–] 15 points 6 months ago (4 children)

    Yep, salt. Also, there are much better options than MD5. I used bcrypt in systems I built a while back. There's also scrypt and argon2, which are newer. (Just be careful that you don't create a DoS vulnerability while hardening your login system...)

  • source
  • parent
  • hideshow 4 child comments
  • [–] 10 points 6 months ago (2 children)

    Yep, and md5 is only used by many because it's so fast. Cutting corners for speed's sake is always going to come with a penalty somewhere.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 6 months ago

    We ran a database of password leaks through a Caesar cypher and you'll never guess how easy they were to break!

  • source
  • [–] 8 points 6 months ago (1 child)

    No one uses MD5 for password security anyway

  • source
  • hideshow 1 child comment
  • [–] 6 points 6 months ago (4 children)
  • [–] 22 points 6 months ago* (last edited 6 months ago) (1 child)

    MD5 is a hashing algorithm (for simplicity, let's wrongly say hashing it's something akin to encrypting) that is very fast to compute. That is bad for password storage, since it means you are vulnerable to a brute force attack; you want the algorithm for password storage to be slow enough to make that attack unfeasible.

    Aditionally, there's also attacks like dictionary attacks, where you can use precomputed hashes of commonly used passwords (that's a reason you shouldn't re-use passwords accross websites: if one of them falls, the rest are vulnerable to dictionary attacks). To prevent these, you use salted algorithms, of which MD5 is not, at least out of the box.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 6 months ago

    That's true.

    But it is even more important to not use the same username across websites and to not use usernames that have anything to do with you as a real person.

    Someone knowing all of your usernames and only one of your passwords is worse than someone knowing all of your passwords and only one of your usernames.

  • source
  • parent
  • [–] 9 points 6 months ago (1 child)

    Probably not the best for this, but to make an attempt:

    So when you store a password you don't (or at least shouldn't) store the actual password.

    Because of some magic some math wizards cobbled together a good while ago, we have some algorithms that take a blob of information and chop it all up in unique (or at least close enough to be called unique) ways. These algorithms make it such that changing a tiny piece of input has a major change on output. This whole thing is called "Hashing".

    So anyway, we don't store the actual password ("in the clear"), instead we store "hashes" of passwords.

    One of the first adopted standards for hashing was Message Digest 5 (MD5). At the time (80's if the memory serves), it was reasonably effective for all the things it was needed for.

    But over time, we've found weaknesses in it. On modern hardware, its not overly difficult to figure out all the password length things that could have been used as input to generate a given hash.

    Nowadays, there's more secure hashing algorithms, but to support legacy software, MD5 is still used. TBH, I don't think it's as big of a deal as the article makes it seem for personal use gear. Its once you step up to small business stuff (where multiple people have access to the same hardware).

    Other commentors have brought up salting, which is a decent way to help with security. Its where you add known info to the password before hashing to make determining the "real" password more difficult.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 6 months ago

    We've known this for more than a decade and its only gotten faster. If people are still using MD5 for secret hashing at this point they have no idea what they are doing or horrible bosses.

  • source
  • [–] 3 points 6 months ago

    I think I gather from this that predictable strings are sort of reversible to hashes.

    For stuff like SQL databases, I suppose I would personally would generate completely random passwords locally on my PC.

  • source
  • A proper hashing function is the one that takes time.

  • source