Don't forget to change the password for your Twitter account, Mr President :^)

>tech companies go balls deep on (((diversity))) programs a few years ago
>their products begin to slowly deteriorate, up until now when they're logging your password in plaintext
It's not just bloated and buggy frontends, all these companies' backends are just as much as a clusterfuck as what you are witness to

what does "unmasked" mean?

>bug

Attached: 1525245820111.jpg (627x733, 121K)

********

Authentication databases are similar to a masked ball. Every account gets a mask so other people aren't able to judge them at a glance.
Twitter fucked up and didn't get everyone a mask so some people were judged based on their outward appearance rather than looking at their personality.

How is this shit even possible? Aren't passwords supposed to be hashed on the client side?

Your info is on Hillary’s backup server

>not hashing in your head
Its like you want your passwords compromised.

>Aren't passwords supposed to be hashed on the client side?
No. They pretty much never are, and for good reason, simple hashes are much easier to break than salted hashes. Hashing it on the client side just exposes the hashing method to the public.
What you should do is rely on the SSL connection for protection and then hash it on the server as soon as it comes in, discarding the plain text variable.

>Hashing it on the client side just exposes the hashing method to the public.
This isn't a problem if you're using a secure hash.
All hashes are pretty much well known, as are most encryption schemes. The security isn't that the hashes are known, its that its not computationally feasible to break them.

If that secure hash is exposed to the client then it is a problem though.
If you know the hashing method, if you know the salt, then a hashed password is much easier to break.
>All hashes are pretty much well known
And you don't know about salting it seems.

That's not how saltin works you retard

>forcing more javascript
Memes aside, don't trust the client, even if it's their password they aren't hashing before sending. It also means if you get the hashed password through some breach you can just send that and the server would accept it instead of hashing it and comparing to the hash.

Salting works in several ways.
Exposing a salt is never a good idea, no matter what way you are doing it.

salts are always in the clear though you idiot.
salts work by increasing the possible results, not by changing the hash function. they just act as an input

Salts work by invalidating precomputed hashes.

Number of possible result is fixed, that's what hashing function is.

Salting just introduces unknown element to the known algorithm so that the attacker doesn't just have to hash dictionary to get all possible inputs, but also has to try different salts.

H(x) -> y
but
h(x,salt) -> y1 - yn
salts change the output, so each input can map to multiple outputs depending on the salt. which is the point. it makes it harder to build a table of possible results where h(password) -> xkso232

its not unknown though. because whatever hashing algorithm you use has to know the salt.

and sure, you could attempt to embed it inside your hash function so it only works with a single salt. But now you made it obvious what your salt is, because if an attacker has an account for example, he knows what his password is and only needs to determine the salt now, and now any assumed added security you had by hiding some salt is destroyed.

That's not really contradicting what I said. I said the result changes based on salt, not the possible count of results. The possible count of distinct output values is dependent on algorithm not salt.

I guess technically yeah. but the number of possible outputs per input was what i was referring to.

>Hello, this is your bank speaking, who is this?
>Hi, it's me, ") DROP TABLE USERS;"
>150M rows removed. Thank you.

No. Otherwise as a Twitter sysadmin you could easily log in as realdonaldtrump without even needing to brute force the passwords.

It's supposed to be sent over TLS and then immediately hashed. But the diversity hires at Github and Twitter don't know that.

Those bugs also mean they log unauthenticated input.

>But now you made it obvious what your salt is, because if an attacker has an account for example, he knows what his password is and only needs to determine the salt now, and now any assumed added security you had by hiding some salt is destroyed.
Which would be only possible if he had access to his hashed password, which he would if you hash it client side, which would require the salt to be client side.

Now if a site he has an account for is hacked and the hashed passwords become available he could try and work out the salt from his hashed password, but again the salt can be anything, you could try rainbow table it but it could just as easily not be plain text so you could be stuck brute forcing it with every byte being anything from 0x00 to 0xFF, and it could then also be unique to the user (though if the user table was dumped the salt may be included in this case).

I think xkcd is cool too

>Aren't passwords supposed to be hashed on the client side?
have you tried using an interception proxy to decrypt your own traffic? try it, and you'll see.

if you did that, the hash would effectively become the password

>"Hey class, to start off the semester lemme open this power point."
>Proceeds to spend 10 minuets trying to switch the output to the projector, one autistic kid is yelling at him in an attempt to help
>"Oh never mind, here is the syllabus"
>It has an xkcd comic on it

I'd imagine whoever manages Trumps Twitter account did that.
Although if I were them I'd use this as an excuse to talk mad shit on Democrats and call them slave owning Communists that use Foxconn suicides as ritual sacrifices then claim my account was hacked.

Attached: 1511471015716.gif (251x173, 95K)

That actually happened to me in college.
>doing presentations in Speech
>people taking 5-10 minutes to get the projector working
>i'm the autistic one yelling that them to just press the windows key and 'p'
>they dont do it and just keep trying to set the projector up like it's a second monitor

Attached: 1515885648868.jpg (540x551, 55K)

It's suffering. Like watching a blind dog trying to play fetch.

All win+p does is toggle your multi-monitor settings

>xkcd reference on day 1
i legit walk out of class and start reading the textbook when this happens

See, shit like this is why everyone should implement SCRAM-SHA-1 or some derivative challenge-response algorithm for password-based authentication.

You can't leak someone's password if you never fucking have it.

I don't have a screencap but Amazon gave me a similar message

>if you know the hashing method
security through obscurity is not security at all.
The point of hashing the client password before it ever reaches the server, as in challenge-response authentication methods, is so that the user's cleartext password never leaves their device.

Who the fuck cares IF your service gets hacked. or you get a data breach. Assume it happens, then plan for it. Chances are the user is using the same password for N different services. Why are you giving a hacker a user's password to not only YOUR service, but maybe even EVERY service that user uses?

savage.

literally use PKI

>hey guys i just learned this in class :)
they were storing hashed passwords you retard
the server has to first receive the password input by user on the login page or whatever in order to hash it to begin with
that was the problem, someone logged the login attempts, the plaintext passwords that reach the server before being hashed and compared against the hash stored in the database

"hurrdurr I can't hash a password prior to registration"

No.

Server side hashing is the only correct way. Client side would introduce vulnerabilities.

And because I know you're a moron and you're going to say something stupid again
"hurr durr I can't hash a password prior to registration and hash it again serverside"

>cryptographic experts introduce salt to improve security of hash algorithms
>salt is meant to be kept secret from the users
>client-side hashing would require revealing the salt to the user
>revealing the hash algorithm used is in itself a vulnerability
>using anything beyond SHA-1 client-side would take too long and SHA-1 isn't secure
>tomorrow it could become trivial to "reverse" a SHA-1 hash
>HURR DURR LE STOP USING SECURITY THROUHG OBSCURITY GUYS I'M AN EXPERT I LEARNED THIS IN CLASS

How did you edit your post?

I don't know
edit: nvm found it

But the client can do more intensive hashing than a server that has to process millions of requests.

how u did that

>bug

Go back to Jow Forums

Wait what the fuck, you can edit your own posts?

edit: Holy fuck you can
Who the fuck thought this was a good idea?

edit2: Also, fuck Hiroshimoot for adding this

Prove he's wrong

You don't realize it was always like that. Yes, every service you use that developed by a major company is a joke full of child's mistakes. The only thing that changed is you being aware of it.

I'm not changing my twitter password. I don't care if some ruski uses it to post propaganda.

>having a twitter account at all

>hurfdurfdruf how am I even able to breathe
stackoverflow.com/a/31776798/8039441