Dremor, (edited )
@Dremor@lemmy.world avatar

Hello, c/Games mod here.

This post has been reviewed as valid by the mod team

For everyone infosec culture, hashing and salting password consist in using one-way mathematical functions to encrypt passwords. It is a very commonly used security practice to make it more difficult for an attacker that was able to steal a database to obtain the password. As the website is unable to decrypt said password (thank to the one way mathematical function), the only way to send you back your password in this manner is to have it unhashed and unsalted in his database.

But

In the current case, this is a registration email, which may have been sent before the initial hashing and salting. In this case we cannot say for sure if Larion Studios indeed have unhashed and unsalted password in his database.

inclementimmigrant, (edited )

While sending your password in plaintext over email is very much a bad idea and a very bad practice, it doesn’t mean they store your password in their database as plaintext.

Serdan,

Passwords shouldn’t be stored at all though 🤷‍♂️

Vlixz,
@Vlixz@lemmy.world avatar

You mean plaintext passwords right? Ofcourse then need to store your (hashed)password!

Serdan,

The hash is not the password.

Vlixz,
@Vlixz@lemmy.world avatar

My bad! I just misunderstood >⁠.⁠<

jmcs,

If they stored the hashed password this thread wouldn’t exist.

TheFogan,

Point is, a hash isn’t a password. giving the most you don’t need tech knowledge analogy, it’s like the passwords fingerprint.

The police station may keep your daughters fingerprint so that if they find a lost child they can recognize it is your daughter beyond any doubt. Your daughters fingerprints, is like a hash, your daughter is a password.

The police should not store your daughter… that’s bad practice. The fingerprints are all they should store, and needless to say the fingerprints aren’t your daughter, just as a hash isn’t a password.

jeeva,

Would you accept “in a way that can be reversed”?

tonkatwuck,

It’s possible that this email is a result of forum user creation, so during that submission the plaintext password was available to send to the user. Then it would be hashed and stored.

Serinus,

I don’t know why you’d give them any benefit of the doubt. They should have already killed that with this terrible security practice.

But yeah, sure, maybe this one giant, extremely visible lapse in security is the only one they have.

tonkatwuck,

I’m just explaining how user authentication works for most web applications. The server will process your plaintext password when your account is created. It should then store that as a hashed string, but it can ALSO send out an email with that plaintext password to the user describing their account creation. This post does not identify that passwords are stored in plaintext, it just identifies that they email plaintext passwords which is poor security practice.

Serinus,

This particular poor security practice is very much like a roach. If you see one you have a bigger problem.

See, I can also repeat myself as though you didn’t understand the first time.

JackbyDev,

Encrypted passwords are still an unacceptable way to store passwords. They should be hashed.

Cloodge,

(and salted before hashing.)

Dicska,

And marinated in butter milk.

Cloodge,

Peppered if you’re feeling extra

Michal,

Just because they send out the password does not mean it’s not hashed. They could send the email before hashing.

JackbyDev,

You’re correct and after reading more of the thread I saw OP say this was sent immediately after registering. I don’t have reason to believe it is stirred in plaintext unless they’re storing s copy of every email they send.

nickwitha_k,

That’s very unlikely. It’s running UBB Threads, which, from what I can tell, has an auth subsystem, which au minimum would do hashing. If it’s providing you with a default at sign-up, that’s different and is what appears to be a configurable setting.

If it is completely generated for you, here’s what probably happening:

  1. User creation module runs a password generator and stores this and the username in memory as string variables.
  2. User creation module calls back to storage module to store new user data in db, including the value of the generated password var.
  3. Either the storage module or another middleware module hashes the password while preparing to store.
  4. Storage module reports success to user creation.
  5. User creation module prints the vars to the welcome template and unloads them from memory.

TL;DR as this is running on a long-established commercial php forum package, with DB storage, it is incredibly unlikely that the password is stored in the DB as plaintext. At most it is likely stored in memory during creation. I cannot confirm, however, as it is not FOSS.

Cabrio,

It sends the user generated password, not an auto generated one.

hex,

Yeah if they send the password in an email in plain text that’s not storing it. You can send the email before you store the password while it’s still in memory and then hash it and store it.

Cabrio, (edited )

Stored in memory is still stored. It’s still unencrypted during data processing. Still bad practice and a security vulnerability at best. Email isn’t E2E encrypted.

oneiros,
@oneiros@lemmy.blahaj.zone avatar

Stored in memory is still stored.

Given what I know about how computers accept user input, I am fascinated to hear what the alternative is.

Cabrio, (edited )

You have the text input feed directly into the encryption layer without an intermediary variable. The plaintext data should never be passable to an accessible variable which it must be to send the plaintext password in the email because it’s not an asynchronous process.

I’m surprised so many people are getting hung up on basic infosec.

frezik,

Are you suggesting to do all this on the frontend before it goes to the backend?

Cabrio,

The front end to backend traffic should be encrypted, hashing occurs on the backend. The backend should never have access to a variable with a plaintext password.

I’m going to have to stop replying because I don’t have the time to run every individual through infosec 101.

reverendsteveii, (edited )

how long have you been a web developer? Because I’ve been doing it for six years and almost every web app I’ve ever seen uses http with TLS to send the plaintext password to the backend, where it’s popped into a request var at the controller level, then passed as an instance var to the service level, salted, hashed and stored. This includes apps that have to submit themselves for HIPAA compliance because they deal with PHI.

Cabrio,

25, I used to write proprietary networking protocols.

reverendsteveii,

shit, I wonder why the protocol that’s much more well-adopted than yours does things differently

Cabrio, (edited )

Imagining thinking what’s popular is best. Betamax, HD DVD, Firewire, Ogg Vorbis, PNG, Firefox, Linux, Lemmy and friends, would all like a chat.

poopsmith,
@poopsmith@lemmy.world avatar

Maybe I’m misunderstanding you, but backend servers will almost always have the user-submitted password in plaintext as a variable, accessible to the backend server and any upstream proxies.

It’s even how it’s done in Lemmy. The bcrypt verify accepts the plaintext password and the expected salted hash.

Cabrio,

Yes, which is why they’re vulnerable to mitm and local sniffer attacks.

frezik,

Have you found a mitm attack on TLS?

Cabrio,

I haven’t looked into it but I was wondering about the logistics of setting up a federated honeypot for server side stream sniffing to build a plaintext email/password database.

canni,

This guy’s a fucking clown, I’m sure he’s like 15

reverendsteveii,

Not without compromised certificates they haven’t. You can tell because if they did they’d be world famous for having destroyed any and all internet security. Then again, they’d probably already be famous for having figured out a way to salt, hash and store passwords without ever holding them in memory first like they claim to do above, so maybe someone is lying on the internet about their vague “proprietary network protocols”.

frezik,

Oh yeah, this guy is a hoot.

Hawk,

Man, you sound like you’re just using random words you heard in class. Clearly you have no clue how user registration actually works, let alone backend development.

Cabrio,

Well it’s a good thing your opinion has no effect on reality.

fireflash38,

There are ways to have passwords transmitted completely encrypted, but it involves hitting the backend for a challenge, then using that challenge to encrypt the password client side before sending. It still gets decrypted on the backend tho before hash and store.

poopsmith,
@poopsmith@lemmy.world avatar

Yeah, but SSL/TLS also solves that problem in a standardized way.

In either case, the backend will have the plaintext password regardless of how it’s transmitted.

frezik,

I asked because what you’re describing doesn’t do much if you understand how common web frameworks and runtime environments work.

The framework needs to parse the HTTP request. That means holding the parameters in a variable somewhere just to arrange them in a datastructure for processing.

But let’s ignore that and say we have some kind of system that stream parses the request right out of the buffer (which itself still needs to be held in memory for a bit, but let’s ignore that), and when it matches a preconfigured password parameter, passes it directly to the hashing system and nowhere else. I don’t think any framework in existence actually does this, but let’s run with it.

We’ll still need to pass that value by whatever the language uses for function passing. It will be in a variable at some point. Since we rarely write in C these days unless we have to, the variable doesn’t go away in the system until the garbage collection runs. Most systems don’t use ref counting (and I think it’s a mistake to disregard the simplicity of ref counting so universally, but that’s another discussion), so that could happen whenever the thread gets around to it.

But even if it runs in a timely fashion, the memory page now has to be released to the OS. Except most runtimes don’t. First, the variable in question almost certainly was not the only thing on that page. Second, runtimes rarely, if ever, release pages back to the OS. They figure if you’re using that much memory once, you’ll probably do it again. Why waste time releasing a page just to make you spend more time getting it again?

And we’re still not done. Let’s say we do release the page. The OS doesn’t zero it out. That old variable is still there, and it could be handed over to a completely different process. Due to Copy on Write, it won’t be cleared until that other process tries to write it. In other words, it could still be read by some random process on the system.

And we haven’t even mentioned what happens if we start swapping. IIRC, some Linux kernel versions in the 2.4 series decided to swap out to disk ahead of time, always having a copy of memory on disk. Even if you’re not running such an ancient version, you have to consider that the kernel could do as it pleases. Yeah, now that var potentially has a long lifespan.

To do what you want, we would need to coordinate clearing the var from the code down through the framework, runtime, and kernel. All to protect against a hypothetical memory attack. Which are actually quite difficult to pull off in practice. It’d be easier to attack the client’s machine in some way.

And on top of it, you’re running around with an undeserved sense of superiority while it’s clear you haven’t actually thought this through.

Cabrio,

Yes. I agree 100% with the things I can and I defer to your experience where I can’t. I used to write proprietary networking protocols 20 years ago and that’s the knowledge and experience I’m leaning on.

As a matter of practice we would ensure to process passwords by encrypting the datasteam directly from the input, and they were never unencrypted in handling, so as to protect against various system and browser vulnerabilities. It would be a big deal to have them accessible in plaintext beyond the user client, not to mention accessible and processable by email generation methods and insecure email protocols.

canni,

I think you’re a liar

Cabrio,

It’s a good thing your opinion makes no difference then isn’t it.

PastaGorgonzola,

I’m going to have to stop replying because I don’t have the time to run every individual through infosec 101.

Sorry, but you’re missing the point here. You cannot do anything with a password without storing it in memory. That’s not even infosec 101, that’s computing 101. Every computation is toggling bits between 1 and 0 and guess where these bits are stored? That’s right: in memory.

The backend should never have access to a variable with a plaintext password.

You know how the backend gets that password? In a plaintext variable. Because the server needs to decrypt the TLS data before doing any computations on it (and yes I know about homomorphic encryption, but no that wouldn’t work here).

Yes, I agree it’s terrible form to send out plain text passwords. And it would make me question their security practices as well. I agree that lots of people overreacted to your mistake, but this thread has proven that you’re not yet as knowledgeable as you claim to be.

Cabrio, (edited )

You encrypt the datastream from the text input on the client side before storing it in a variable. It’s not rocket science. I did this shit 20 years ago. Letting a plaintext password leave the user client is fucking stupid.

Atomic,

If they can send you, your own password in plain text. That’s already bad enough. Just not good practise.

beefcat,
@beefcat@lemmy.world avatar

there is no possible way to handle sensitive data without storing it in memory at some point

it’s where you do all the salting, hashing, and encrypting

emailing out credentials like this after sign up is certainly not best practice, but probably not a huge deal for a video game forum of all things. if you are re-using passwords then you already have a way bigger problem.

JackbyDev,

emailing out credentials like this after sign up is certainly not best practice,

Understatement of the year right here. Everyone in this thread is more interested in dunking on OP for the few wrong statements they make rather than focusing on the fact that a service is emailing their users their password (not an autogenerated “first time” one) in plaintext in an email.

RonSijm,
@RonSijm@programming.dev avatar

there is no possible way to handle sensitive data without storing it in memory at some point

Since we’re nitpicking here - technically you can. They could run hashing client side first, and instead of sending the password in plain-text, you’d send a hashed version

beefcat,
@beefcat@lemmy.world avatar

but then you expose your salt to the public

RonSijm,
@RonSijm@programming.dev avatar

No, the client side hashing doesn’t substitutes anything server side, it just adds an extra step in the client

ilinamorato,

This opens up the possibility of replay attacks in the case of data breaches, though, and those are much more common than http mitm attacks (made even less likely with the proliferation of https).

I’m not entirely sure whether hashing twice (local and server) is wise, having not thought through that entire threat vector. Generally I try to offload auth as much as I can to some sort of oauth provider, and hopefully they’ll all switch over to webauthn soon anyway.

RonSijm,
@RonSijm@programming.dev avatar

I’m not really sure how it opens up replay attacks, since it doesn’t really change anything to the default auth. There are already sites that do this.

The only difference is that instead of sending an http request of { username = “MyUsername”, Password = “MyPassword” } changes to { username = “MyUsername”, Password = HashOf(“MyPassword”) } - and the HashOf(“MyPassword”) effectively becomes your password. - So I don’t know how that opens up a possibility for replay attack. There’s not really any difference between replaying a ClearText auth request vs an pre-hashed auth request. - Because everything else server side stays the same

(Not entirely auth related), but another approach of client side decryption is to handle decryption completely client site - meaning all your data is stored encrypted on the server, and the server sends you an encrypted container with your data that you decrypt client side. That’s how Proton(Mail) works in a nutshell

ilinamorato,

I’m not really sure how it opens up replay attacks

Put simply, jt allows an attacker with a leaked database to use the hashed password as a password. In your original comment, it seemed like you were suggesting hashing only before transmission, on the client; but hashing both before and after would indeed patch that particular vulnerability. I don’t know if there are potential problems with that strategy or not.

another approach of client side decryption is to handle decryption completely client site

Here’s potentially an opportunity for me to learn: how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? Since you can’t count on a web browser to have the private key, do you send down an encrypted private key that can only be decrypted with the user’s password? Is there some other way to do this that I’m not aware of?

RonSijm, (edited )
@RonSijm@programming.dev avatar

In your original comment, it seemed like you were suggesting hashing only before transmission

Ok, that wasn’t what I was suggesting, no. That would effectively make your password hash the password itself - and it would kinda be stored in PlainText on the server, if you skip the client auth and send that value to the server directly through the api or something

how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? […] do you send down an encrypted private key that can only be decrypted with the user’s password?

Yes, pretty much. I can’t really find a good, detailed explanation from Proton how it exactly works, but LastPass uses the same zero-knowledge encryption approach - which they explained with some diagram here - with a good overview of the client/server separation of it’s hashing.

ilinamorato,

Awesome. Thanks for the links and the info.

vox,
@vox@sopuli.xyz avatar

no, they probably dont.
they just send it to your email upon registration, which is kinda a bad idea, but they are probably storing passwords hashed afterwards.

tb_, (edited )
@tb_@lemmy.world avatar

But that still means they had your plaintext password at some point.

Edit: which, as some replies suggest, may not actually be much of an issue.
I’m still skeptical about them returning it, however.

Kilamaos,

Of course. You receive the password in plain on account creation, do the process you need, and then store it hashed.

That’s fine and normal

kadu,
@kadu@lemmy.world avatar

deleted_by_author

  • Loading...
  • Vegasimov,

    When you create an account you type your password in. This gets sent to the server, and then it is hashed and stored

    So there is a period of time where they have your unhashed password

    This is true of every website you have ever made a password on

    dangblingus,

    So why would an agent at Larian have man-in-the-middle access between the password being sent to the server, and the auto-hash?

    kadu,
    @kadu@lemmy.world avatar

    deleted_by_author

  • Loading...
  • Vegasimov,

    I’ve never even heard of the game studio I’m not defending them, I was replying to the person who said the company should never have your unhashed password, and explaining that they have to at some point in the process

    vox,
    @vox@sopuli.xyz avatar

    hashing on client side is considered a bad idea and almost never done.
    you actually send your password “in plain text” every time you sign up.

    wim,

    It’s not a bad idea and it is often done, just not in a browser/webapp context.

    hotdoge42,

    Can you give an example where this is done?

    wim,

    Sorry, I should have included an example in my comment to clarify, but I was in a rush.

    HMAC is a widely used technique relies on hashing of a shared secret for verifying authenticity and integrity of a message, for example.

    sleepy555,

    Really everytime you log in too.

    Hexarei,
    @Hexarei@programming.dev avatar

    Um. Yeah, because you provided it to them. They have to have it in plain text in order to hash it.

    TheEighthDoctor,

    So it’s in plaintext in their email system

    Thadrax,

    Generated emails usually don’t get saved, as soon as it is delivered it will be gone.

    vox,
    @vox@sopuli.xyz avatar

    these emails don’t usually get copied to local outbox folder (as any oher auto generated emails)

    password may end up in cache somewhere tho…
    and this is why it’s a bad idea and rarely done nowadays

    Mirodir,

    …and if they keep the emails they send out archived (which would be reasonable), they also have it stored in plaintext there.

    Thadrax,

    Automatically generated emails usually don’t get saved.

    glitches_brew,

    As the designated email dev at my company I can confidently say this is not true.

    Not saying that this specific email is persisted, but almost all that I work with are. It’s a very common practice.

    Rambomst,

    Yeah, we save most emails sent out at my work.

    tocopherol,
    @tocopherol@lemmy.dbzer0.com avatar

    I wonder how much this varies depending on the amount of data it would require to store the emails of a company. I know nothing about this subject, but does it occur where companies with very large email lists would forgo storing those types of emails to save data costs?

    glitches_brew,

    In my experience it varies a lot. Even in our own system certain emails are stored differently. There are a few “we legally have to deliver this email and might need to prove it later” notifications. We store a PDF of those in s3. For others we might just save the data, a sent timestamp, and a key for which email visual template was used.

    I also thought of a counter argument to my point overnight. We don’t store one super duper high volume email which is the email that only has an MFA code. We would also absolutely never ever dream about allowing a plaintext password in an email, so we’re probably following different patterns in the first place.

    dangblingus,

    I’ve literally never had a service provider email me my own password ever. Maybe a OTP, but never my actual password. And especially not in plaintext.

    What would be the necessity behind emailing someone their own password? Doesn’t that defeat the purpose of having a password? Email isn’t secure.

    wim,

    I find that very hard to believe. While it is less common nowadays, many, if not most, mailing list and forum software sent passwords in plaintext in emails.

    A lot of cottage industry web apps also did the same.

    EssentialCoffee,

    They’re probably just young.

    benjacoblee,
    @benjacoblee@lemmy.world avatar

    Idk if I’m misremembering, but it’s my impression that they did this a lot in the 2000s, haha. I guess bad practices have a habit of sticking around

    EssentialCoffee,

    I’ve had service providers physically mail my own password to me before. Just crazy.

    Always use unique passwords for every site.

    darkkite,

    this is still a terrible idea. the system should never know the plaintext password.

    logs capture a lot even automated emails. i don’t see a single reason to send the user their plaintext password and many reasons why they shouldn’t

    vox,
    @vox@sopuli.xyz avatar

    passwords are usually hashed server-side tho and that’s done for a reason.
    if handling passwords correctly, server side hashing is way more secure then client-side. (with client side hashing, hash becomes the password…)

    JackbyDev,

    “Kinda a bad idea?” This is fucking insane.

    Umbraveil,

    Is it though? While it certainly isn’t something I’d recommend, and I’ve encountered it before, if E2E encryption exists we cannot assume a data exposure had occurred.

    What they do on the backend has nothing to do with this notification system. Think of it as one of these credentialess authentication systems that send a ‘magic link’ to your inbox.

    hperrin,

    You can also tell if a site does this when they have seemingly arbitrary restrictions on passwords that are actually database text field restrictions.

    Especially if they have a maximum password length. The maximum password length should be just the maximum length the server will accept, because it should be hashed to a constant length before going into the database.

    icedterminal,

    I recently created an Activision account during a free weekend event and discovered their password system is completely broken. 30 character limit but refused to accept any more than 12 characters. Kept erroring out with must be less than 30. Once I got it down to 12 it accepted that, but then it complained about certain special characters. Definitely not giving them financial information.

    Darkassassin07,
    @Darkassassin07@lemmy.ca avatar

    My bank has a character limit, but they don’t tell you about it; they just trim the password you’ve set before hashing + saving it, then when you go to login if you don’t trim your password the same way they did, login fails.

    I only know this because the mobile app will actually grey out the login button as soon as you enter more than the character limit. The web app just leaves you to be confused.

    icedterminal,

    What an absolutely shitty design.

    Chobbes,

    I had a similar situation with my health insurance company, except I think they added the character limit a while after I had set my password T_T. So, it worked for months, then they changed the mobile app so I couldn’t enter a long password… And then eventually they changed the website too and then I couldn’t log in at all. Thaaaaanks.

    turbowafflz,

    Isn’t this also what Windows NT used to do? I feel like I remember encountering this scenario

    DSTGU,

    Doesnt lemmy also do it? I think I ve heard from Ruben at Boostforlemmy that lemmy only treats first 60 characters of your password as a password and the rest gets discarded. [citation needed]

    Darkassassin07,
    @Darkassassin07@lemmy.ca avatar

    Can’t say I’ve ever tried to use a password quite that long, so I’m not sure.

    Not ideal, but trimming it (especially when you’re keeping 60 chars) isn’t the end of the world. It was just super confusing that the web app doesn’t trim it during login as well. There’s no indication that your password was modified or what you’ve entered to login is too long. Just ‘incorrect user/pass’ despite entering what you’ve just set. That char limit for my bank is only 16 chars, so it’s easy to hit.

    wols,

    It’s a big deal IMO, particularly because at login it doesn’t do the same. From the user perspective, your password has effectively been modified without your knowledge and no reasonable way of finding out. Good luck getting access to your account.
    When a bank does this it should be considered gross negligence.

    exal,
    @exal@lemmy.ca avatar

    Kind of.

    The official web UI doesn’t let you enter more than 60 characters, but doesn’t indicate that at all. So you can keep typing past 60 characters but it won’t get added to the input field and you can’t really see that. If you paste a password into the field, it gets trimmed to 60 characters.

    When creating a password, the server checks that it isn’t longer than 60 characters and returns an error if so. On login, however, it silently trims the password to 72 bytes, because that’s what the hashing algorithm they use supports.

    Jezzdogslayer,

    My bank if you get your card number through the app has a dynamic ccv that changes every day so while not perfect is what I use whenever purchasing online

    exal,
    @exal@lemmy.ca avatar

    Especially if they have a maximum password length.

    Not really, there are good reasons to limit password length. Like not wanting to waste compute time hashing huge passwords sent by a malicious actor. Or using bcrypt for your hashes, which has a 72 byte input limit and was considered the best option not that long ago. The limit just has to be reasonable; 72 lowercase letters is more entropy then the bcrypt hash you get out of it, for example.

    hperrin,

    Yes, reasonable limits are fine, I was talking more like 12 or 13 characters max. That’s probably indicative of a database field limit, and I’ve seen that a fair amount because my password manager defaults to 14 characters.

    slazer2au,

    Set your password to an EICAR test string and see what else you can brick on their site.

    sysadmin420,

    Holy shit beautiful. Now I wanna try it everywhere

    CurlyMoustache,
    @CurlyMoustache@lemmy.world avatar
    1984,
    @1984@lemmy.today avatar

    It’s 2023, I really hope people are not using the same password in multiple places. Password managers solved this problem a decade ago. Use one, with multi factor auth on important sites like email.

    Kolanaki,
    @Kolanaki@yiffit.net avatar

    I’ve used the same password for everything since 1991. If anyone’s cracked it, they haven’t attempted to get into my shit. Probably because there’s nothing worthwhile to steal.

    gornius,

    “I’ve never had covid, so it doesn’t exist” vibes.

    1984,
    @1984@lemmy.today avatar

    If you dont care, just give me your password then. :)

    Kolanaki,
    @Kolanaki@yiffit.net avatar

    It’s *********.

    Edit: I guess the site autohides passwords? 🤷🏻‍♂️

    1984,
    @1984@lemmy.today avatar

    I tried putting the stars in there and it didn’t work!

    :)

    Bitrot,
    @Bitrot@lemmy.sdf.org avatar

    hunter2

    Hey, you’re right!

    Nibodhika,

    First of all they wouldn’t know there’s nothing worthwhile until they got in. But most importantly if you’re using the same password for everything since 91 there’s around a 0% chance that password hasn’t been leaked. This means that a random person can have access to everything that you have that’s not 2fa protected without you even noticing. You said that no one tried to get into your things, how would you know? Most places don’t let you know when someone login successfully, and a lot of other places do so with an email which the attacker can quickly delete.

    If you really use the same password for everything since a long while back anyone who knows your email address can get into anything yours, getting a hold of one of those password dumps is really easy, especially older ones.

    AssPennies,

    if you’re using the same password for everything since 91 there’s around a 0% chance that password hasn’t been leaked

    Plot twist, they’ve never had their password leaked due to never having a password.

    They spend every last waking moment trolling through public or university libraries to find computers that people haven’t logged out of, and are still logged into social media, dialup modems, irc, bbs, mainframes, etc. It’s these accounts they make posts from.

    Pretty lonely world when you only ever get to make one comment on one account at max like once a week. And then you never get to check the replies. You never get to check your email either, you don’t know if anyone has sent you and e-card for your birthday.

    Oh and not to speak of constantly getting kicked out of those libraries once the librarians recognize you. To the point where you have to move to yet another city to have any online time again.

    But hey, they’ve never had their password leak at least!

    Nibodhika,

    Like I said, almost 0%, there’s always a chance he’s the Phantom of the Library.

    Kolanaki,
    @Kolanaki@yiffit.net avatar

    Hey! Stop telling people my secrets!

    Kolanaki,
    @Kolanaki@yiffit.net avatar

    First of all they wouldn’t know there’s nothing worthwhile until they got in.

    I mean, you can read all my comments and posts publicly, and social media accounts and such are just about the only thing I’ve ever had passwords for. 🤷🏻‍♂️

    You finna steal my Lemmy account?

    Security is only important when you give a shit about what can be taken without it.

    mojo,

    Bro that’s dumb as hell

    GBU_28,

    Since 1992 I just use his creds and sign up for a bunch of shit

    ChaoticEntropy,
    @ChaoticEntropy@feddit.uk avatar

    It’s cool… the password is “password123”, who would even expect that? It’s uncrackable.

    jj4211,

    That’s the password on my luggage!

    Honytawk,

    Your luggage password has letters in it?

    Bitrot,
    @Bitrot@lemmy.sdf.org avatar

    He’s a real Spaceball.

    Honytawk,

    There are people who purposely forget their passwords, so they use the “forgot my password” link every time they need to login.

    Hard to hack them.

    1984,
    @1984@lemmy.today avatar

    Yeah some sites also dont have passwords, they just send a login link to your email every time.

    I prefer passwords so I don’t have to go to my email to log in, but I understand it’s easier for some people to do it that way. Your email address becomes your identity then.

    hex,

    That’s just 2FA with extra steps

    emptyother,
    @emptyother@programming.dev avatar

    Oh, they are. I keep telling people to WRITE DOWN YOUR PASSWORDS, and NEVER use same password on two sites. They dont listen. Its a lot easier to just remember 1-4 variations of a password and use that than carry around a password notebook. And they think themselves safe.

    I’m thinking most people shouldnt use passwords at all anymore. They are a huge point of failure because people are people. We need something else to be the norm. How can we make hardware keys or something the norm for logging in? Have everyone carry around a bankcard-like thing that fit into every computer where people need credentials. Would’nt that be safer while still being accessible and convenient?

    1984,
    @1984@lemmy.today avatar

    There are yubikeys you can use to login, but it requires installing stuff on each computer you want to access. Nothing is simpler then passwords. :)

    I used a yubikey for a while, they are alright, but I could only use it for logging on to a computer, not for logging into specific sites. Even though I guess that could be solved with a password manager integration.

    emptyother,
    @emptyother@programming.dev avatar

    Nothing is simpler than passwords. But we want something thats both simple and safe. Even for lazy people, tech-unsawy people, and people with bad memory.

    What if every pc came with a jubikey-ish reader and every website supported a browser api for it? Probably not jubikey, but something that fit in a wallet like bank cards do (but also was an open tech so that anyone can implement and sell cards). Wouldn’t it be both safer and simpler than passwords? It would take some time to turn around of course but the same was probably the case for https, 2fa, ipv6, and tpm’s.

    Bitrot,
    @Bitrot@lemmy.sdf.org avatar

    Those are called smart cards. Traditional smart cards needed centralized management of credentials, but FIDO2 smart cards exist that work like the keys. The reason tokens are more typically USB-based (or NFC) is every PC has USB, but most don’t have smart card readers.

    Chobbes,

    It would take some time to turn around of course but the same was probably the case for https, 2fa, ipv6, and tpm’s.

    Oh yeah… Definitely good IPv6 support everywhere. That really turned around, and we’re not dragging our feet on implementing IPv6 at all 🥲.

    Bitrot,
    @Bitrot@lemmy.sdf.org avatar

    FIDO2 can be used for passwordless log in on a few sites, but the site and browser need to support the feature (no extra installation). It sets a pin on the yubikey and when entered the key does all the authentication. It will likely be seen more as Apple “passkeys” gain more popularity, Windows and Android already have native support but don’t market as hard.

    thisbenzingring,

    suggest something like this

    use your favorite password but add the site to it

    so your lemmy password would be ilovemypasswordLEMMY

    and your reddit password would be ilovemypasswordREDDIT

    that way they can keep their shitty password but it won’t be the same password on every site and they have an easy way to remember what the proper password is for the site they want to accesss

    docwriter,

    I used to do this, but I realized that if someone got access to any of my passwords, they would easily spot the pattern.

    In the end, using a password manager and generating large random passwords for each site was the best solution I found.

    thisbenzingring,

    Still better than using the same password. My argument is if you can only convince them to do at least that, it’s better than every site using the same password

    wahming,

    That’s horrible if you ever become the victim of a targeted attack. Compromise your password once on some random shitty site and they’ve got access to everything.

    It’s also quite likely that incidents involving password dumps will have crackers filtering the dumped data looking for exactly passwords like this.

    thisbenzingring,

    This will create individual passwords which is better than the same password everywhere. If it’s the least they will do, it’s better than not.

    Chobbes,

    Oh, they are. I keep telling people to WRITE DOWN YOUR PASSWORDS, and NEVER use same password on two sites. They dont listen. Its a lot easier to just remember 1-4 variations of a password and use that than carry around a password notebook. And they think themselves safe.

    Honestly, the best solution for this is a password manager and not a notebook. The average person is not going to come up with strong passwords on their own for every website. A password manager once setup can be more convenient than whatever they were doing before, so if you can get people to use one they’ll be in much better shape.

    I’m thinking most people shouldnt use passwords at all anymore. They are a huge point of failure because people are people. We need something else to be the norm. How can we make hardware keys or something the norm for logging in? Have everyone carry around a bankcard-like thing that fit into every computer where people need credentials. Would’nt that be safer while still being accessible and convenient?

    My understanding is that this is basically what the whole passkeys initiative is. I have sort of mixed feelings on it. Hardware tokens for logging in is great, but I worry about people stealing the hardware tokens from others. Mostly people are going to use their phones, though, which should have some other mechanism of authentication.

    Miclux,

    deleted_by_author

  • Loading...
  • lwuy9v5,

    what a stupid comment

    Miclux,

    Show me where the proof is that they STORE it plain text. This is just a screen of a mail after creating an account.

    Cabrio,

    They can’t send it if they haven’t stored it, that’s the proof. Whether temporary or not it’s a weakness and attack vector for obtaining unhashed passwords. And if they stored it, it should be immediately hashed at which point they can’t send it.

    towerful,

    They can still send it while the value is in memory.
    But it’s unlikely that emails are sent synchronously. At which point, it has to be added to a job queue somewhere which might not be in memory.
    There is also the communication with that job queue, and logging along the way, and any email logging.
    Email isn’t secure, either.

    So, it bad practice regardless.

    Thankfully larian did address this, and fixed the issue as pointed out by another commenter.
    Addressed here, with the follow up of fixing it:
    forums.larian.com/ubbthreads.php?ubb=showflat&amp…

    And that was back in 2020. 3 years ago.

    rikudou,
    @rikudou@lemmings.world avatar

    That… is not how it works. It is usually hashed and at the same time an email is sent. Meaning it’s not stored plaintext in any storage.

    Cabrio,

    You’ll forgive me for not trusting anyone who can tell me my password that isn’t me.

    Miclux,

    That’s a totally different statement than that in your post.

    Cabrio,

    Sure, if you’re illiterate.

    Miclux,

    Arguing is not your thing, buddy? 🤡

    Cabrio,

    If self awareness was a disease you’d be the healthiest person alive.

    redcalcium,

    Plenty of website did this… more than a decade ago, and even then plenty of security conscious people writing blogs and posting on social media begging devs to stop doing this.

    vox,
    @vox@sopuli.xyz avatar

    they can send it without storing. In fact a lot of websites (mostly small outdated forum systems) send your password to your email before storing it.

    Miclux,

    It’s so sad that you spread misinformation based on your inadequate knowledge.

    Cabrio,

    Lmao

    Krakatoacoo,
    @Krakatoacoo@lemmy.world avatar

    For those who haven’t made accounts yet, you don’t actually have to make an account to play Larian Studios games.

    lowleveldata,

    Don’t use a password there that you’ve used anywhere else

    Just get a password manager already

    JoMiran,
    @JoMiran@lemmy.ml avatar

    This is the correct answer.

    Ledivin,

    I just wanted to drop a reminder that both LastPass and Norton LifeLock have been hacked within the past year alone.

    SaltySalamander,
    @SaltySalamander@kbin.social avatar

    I just want to drop a reminder (to you specifically) that you don't have to use a cloud-based password manager. Roll your own.

    SomeRandomWords,

    Can I discourage rolling your own password manager (like using a text doc or spreadsheet) and instead recommend what you hopefully meant, self-hosting your own password manager?

    AnonTwo,

    I don't know what you're trying to say. I think it was safe to assume Salty probably meant the local-based keepass or something like that?

    I wouldn't have immediately gone to text doc or spreadsheet. those aren't password managers.

    DrQuint,

    The only annoying part about the modern world is that you want to have that keepass file synchronized between devices, at which point you either go down the path of something like Synchthing (not mainstream user friendly) or you just end up asking yourself “fine, what cloud service do I trust to not go looking at my files?”

    melooone,

    I always synced my database manually either directly over usb, or wifi (KDE Connect). I have to admit that it’s not really user friendly, but once I got used to it, it’s no problem at all.

    And uploading it to any cloud service should be fine as long as it’s encrypted with a strong password. But that kind of defeats the point of an offline password-manager in my opinion.

    Hexarei,
    @Hexarei@programming.dev avatar

    I have mine in a self hosted Nextcloud instance, best of both worlds

    h_a_r_u_k_i,
    @h_a_r_u_k_i@programming.dev avatar

    Good advice only for tech-savvy and people who are interested in self-hosting. There’s so many things that can go wrong like improper backups and accidental networking problems.

    lowleveldata,

    Use KeePassXC and you can’t get hacked

    DrQuint,

    Well, you can. But you have to be PERSONALLY hacked. At which point you’re at a level of risk equal to “will my house burn and my notebook full of passwords get lost?”

    neatchee,

    And here’s a reminder that trusting centralized service with high security access control is usually a bad idea.

    I stay away from LastPass for the same reasons I stay away from TeamViewer. Security through obscurity on top of decoupling my security interests from others means other people being attacked is much less likely to cause me harm at the same time

    Hexarei,
    @Hexarei@programming.dev avatar

    Offline password managers like KeepassXC are a thing, plus self hosted remote storage like Nextcloud means you’re not worried about any third party interference

    neatchee,

    I use Pleasant Password Manager, which is keepass compatible. Big fan of offline cache with online sync for access anywhere with an internet connection on top of my phone offline

    Kbin_space_program,

    KeePass is a thing that exists and is fantastic.

    Vash63,

    And at least for LastPass no passwords were compromised. Saying they “were hacked” and leaving the extent of the hack out implies something worse IMO, it’s misleading. The safes themselves are E2E encrypted so they also don’t have your password.

    That said, my vote is to Bitwarden as it’s open source and allows self hosting if you think you’re a more reliable admin than they are. Open plus more choice is always better.

    Kangie,

    And at least for LastPass no passwords were compromised

    I’m just going to leave this here:

    krebsonsecurity.com/…/experts-fear-crooks-are-cra…

    BigDiction,

    This is true, but they have your encrypted vault, and all the technical data to make unlimited informed attempts at cracking it. If you used LastPass, you definitely need to be changing passwords for your critical services at a minimum.

    ram,
    @ram@bookwormstory.social avatar

    Just this month a link was made between $35 million in crypto being stolen and the 150 victims being LastPass users.

    In 2022 Lastpass was compromised through a developer’s laptop and had customer data like emails, names, addresses, partial credit cards, website urls, and most importantly vaults stolen last year, and given they’re closed source, have no independent audits, and don’t release white papers, we have no idea how good their encryption schemes actually are nor if they have any obvious vulnerabilities.

    In 2021, users were warned their master passwords were compromised.

    In 2020 they had an issue with the browser extension not using the Windows Data Protection API and just saving the master password to a local file.

    What will 2024 bring for LastPass? They were hacked, and there’s no reason to think they won’t see more breaches of confidential customer information and even passwords in the future. This is a repeated pattern, and I’d better trust a post-it-note on my monitor for security than LastPass at this point.

    TigrisMorte,
    Spacecraft,

    I want to suggest 1Password even though it’s not free (I used bitwarden for many years though). It has its own SSH agent which is a dream.

    Belazor,

    The only problem with their SSH agent is, if you store let’s say 6 keys and the server is set to accept a maximum of 5 keys before booting you, and the correct key happens to be key number 6, you can end up being IP banned.

    This happened to me on my own server :P

    That being said, my experience was using the very first GA release of their SSH Agent, so it’s possible the problem has been sorted by now.

    miroppb,
    @miroppb@kbin.social avatar

    BitWarden is awesome. Been using it since 2 of my colleagues went to work for them

    brb,

    How is this better than Firefox built-in password manager?