OP would do well to responsibly report it, rather than stirring up drama over a web forum account.
¿Porque no los dos?
Took them 23 years to fix it last time, seems public awareness would be important in the interim, no?
OP would do well to responsibly report it, rather than stirring up drama over a web forum account.
¿Porque no los dos?
Took them 23 years to fix it last time, seems public awareness would be important in the interim, no?
Well it’s a good thing your opinion has no effect on reality.
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.
If self awareness was a disease you’d be the healthiest person alive.
Sure, if you’re illiterate.
Lmao
It’s a good thing your opinion makes no difference then isn’t it.
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.
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.
Imagining thinking what’s popular is best. Betamax, HD DVD, Firewire, Ogg Vorbis, PNG, Firefox, Linux, Lemmy and friends, would all like a chat.
Yes, which is why they’re vulnerable to mitm and local sniffer attacks.
25, I used to write proprietary networking protocols.
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.
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.
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.
It sends the user generated password, not an auto generated one.
You’ll forgive me for not trusting anyone who can tell me my password that isn’t me.
You mean “Gun Manufacturing” (Mechanical Engineering), “Bunker Building” (Civil Engineering), “Things Hitting Things” (Physics), “Explosives, Toxins, and Poisons” (Industrial Chemistry), “DIY Alternative Medicine” (Pharmaceutical Chemistry), “Owning the Libs” (Law), “Ripping off the IRS” (Taxation and Accounting), “How to be Offensive” (Language theory, reading/writing comprehension), “How to win at Gambling” (Mathematics, Statistics) “Why Libs Think Like Pussies” (Philosophy), “War” (Geography, Geo-politics, International Studies).
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.
Image was taken immediately before posting. The issue, apparently, has since shown up again.