how different slashdot would be if they could have a minimum requirement to post of “must not live with parents,” or “must be able to prove you have lived on your own, as an adult, holding down a full time job x 1 year at least”. I suspect there’d be marked improvement.
There are a bunch of things in life that should have those requirements. I feel it would make life much better.
Isn't there more women than men? Wouldn't all men technically be a minority? I think the women are sexist, and choose to have more female babies than male. I Demand!! more male babies to make everything fair. That is all.
In slashdot, and the GP's defense, if you couldn't figure out how to do that from RTFA with all the pictures and wot not showing exactly what to do... you dont even belong on this site.
Yes all routers are a NAT, thats not the issue. The issue is everybody wants to see their cameras when they're away, Consumers, Businesses, Everybody! So the tech that installs the system opens the ports necessary in the router for the people to have outside access to the system. The problem isn't that they forward ports.. The problem is that the vendors have such shitty security on their devices once that port, or more likely multiple ports get forwarded, chances are there is more than one way past that device directly onto your network now.
are created and stored on an authenticator by the user agent in conjunction with the web application.
Its a good idea to not transferring the password, ill give it that.. or it seems so i only read the first page or so TENR(too early not reading).
The problem is now that password/phrase/key is stored on the client.. the client is the most insecure part of this whole process. 99% of people that end up being vulnerable when this stuff happens run windows. windows without a bunch of work is normally easy to break into. Now were back at the password manager issue we had a few years ago, Are the keys encrypted on the client side still requiring a password to unencrypt? that may mitigate this area i worry about. If not its no better than sending the plaintext password across the internet. botnets are everywhere and everywhen. they scan large, and i mean LARGE chunks of the internet with 0day exploits. then you also have the drive by web attacks. and well we can go on for days on that part. I feel what you have showed me helps, but only moves the risk to the less secure side of the equation.
So essentially after ~30(?) years HTML is still shitty. I kindof figured that from the other posts. Maybe browsers could implement the rolling hashing portion of the deal, allowing the rest of those fields to be fulfilled. There has to be safer ways to do this. Sending plaintext passwords to anybody is a bad idea honestly. Negligence like this is the main reason, a lot of us have known this but your information isnt safe outside of your own network..
youre looking at it wrong, the employees that had access to that log probably had access to that whole site. they could do whatever they wanted with your information you have stored there whether there was a password or not. now $randomhacker gets ahold of that log, and starts testing user pass combos on other sites.. with a pre hashed password.. he gets nothing. with the plaintext password sent from $pleb1 used on $site1-12 $randomhacker gets $popularsite2-4 login information for $pleb1. make any more sense what im talking about.. minimize risk during breeches. because the breeches are going to happen, too much new development on the internet to not happen. you cant secure from thousands of changes a day.
there is a difference between a user password, and a salted hash. one is safer than another to transmit. and they can both be re hashed on the other side, it just becomes less exposing to do it one way and not another, also prevents a breech in one service from effecting another unless its a source copy.
So your password is 'hunter2', and clientside, you hash that to 'asdflkjh1234poiu'. That still has to be sent back to the server, and the server has to validate it somehow. Congrats, your password is now 'asdflkjh1234poiu'. It doesn't matter that I don't know that you typed in 'hunter2' to get to 'asdflkjh1234poiu', all I care about is that if I send 'asdflkjh1234poiu' down the wire in the password field with username 'Highdude702', the server lets me in. I don't care that your password is 'hunter2' and not 'asdflkjh1234poiu', I care about accessing your account.
Ok so as someone has already stated.
if you did use client-side hashing in the first place, and only stored a one-way hash of the already hashed&salted password, you could indeed consider 'asdflkjh1234poiu' your password - TO ACCESS THIS ONE SPECIFIC SERVICE (Twitter). There would however never have been such massive headlines of a leak, because users' plaintext passwords - that they use in many different services - would not have been leaked.
Thanks AC
Now, Like he says.. YOU dont have my real password for one. but whats stopping the server from then hashing the hash I send if they think theyre going to get hacked? I dont understand why you guys are throwing the baby out with the bath water.. I dont give a fuck if someone gets a salted hash of my password. because they have no fucking idea what my real password is. also there is no chance of them doing the apparently common thing of storing it in clear text(i say its common because if you try to claim it isnt then you havent actually been paying attention) It is INSECURE to send YOUR password in clear text to any service or server.. Why does sending the plaintext password become more secure than not sending it? I dont get it. Nobody has been able to explain to me how somebody gets my actual password the way i suggest doing it. the way thats common to do it today. well there are databases with billions of passwords for everybody to see thanks to it.
Ok, first stop using MD5? that sounds like a start. second, encypted session(lets get as secure as we can before we do any auth) server says who are you, client says im John Smith. Server says how do you expect me to believe you, here is an algorithm.. the same as the one you signed up with(you can even do a rolling algo with a flag in the database per user) also heres a salt to use. client says, second mate i need to run this shit quick ill get back with you in a second. client hashes, sends hash over encrypted channel. server responds, ahh Hello John! Welcome.. or it says OI FUCK YOU CUNT YOURE NOT JOHN GTFO! idk its early im sober. seems more secure than sending plaintext secrets over any protocol, encrypted or not. I dont understand what is so insecure about this, that makes sending the plaintext password more secure using the same methods.. it just doesnt seem like people are thinking before they type. i have literally been called a moron because i suggest sending a hash in place of the plaintext password. like someone is gonna read the hash.. but some how would not have been able to read the plain text password. I by no means have a formal education in security, but i have been in the "streets" of the internet since i was a kid and ive seen just about every type of security broken at some point. its not a matter of IF its WHEN. So we need to try to secure as much as possible before that happens. and to me that means my plaintext password never leaves my NIC. Looking forward to your reply.
But honestly, This should be handled client side not server side. that plaintext password should never be sent over HTTPS even, I haven't played with web development in about 20 years, so I cant say how easy this is to do. But I can say that if its not easy to do in HTML/CSS/PHP/Whatever is used, there is something wrong with the language and it should probably never be used for secure access to anything. Just my 2 pennies worth.
Slashdot Mirror
Federal prison is a lot more fair than state prison that's for sure.
how different slashdot would be if they could have a minimum requirement to post of “must not live with parents,” or “must be able to prove you have lived on your own, as an adult, holding down a full time job x 1 year at least”. I suspect there’d be marked improvement.
There are a bunch of things in life that should have those requirements. I feel it would make life much better.
The people of compassion and tolerance, give it up for AC.
I would find no choice for myself but to hunt down and kill every cop involved had it happened to me.
Isn't there more women than men? Wouldn't all men technically be a minority? I think the women are sexist, and choose to have more female babies than male. I Demand!! more male babies to make everything fair. That is all.
In slashdot, and the GP's defense, if you couldn't figure out how to do that from RTFA with all the pictures and wot not showing exactly what to do... you dont even belong on this site.
Yes all routers are a NAT, thats not the issue. The issue is everybody wants to see their cameras when they're away, Consumers, Businesses, Everybody! So the tech that installs the system opens the ports necessary in the router for the people to have outside access to the system. The problem isn't that they forward ports.. The problem is that the vendors have such shitty security on their devices once that port, or more likely multiple ports get forwarded, chances are there is more than one way past that device directly onto your network now.
I got to here and cringed
are created and stored on an authenticator by the user agent in conjunction with the web application.
Its a good idea to not transferring the password, ill give it that.. or it seems so i only read the first page or so TENR(too early not reading).
The problem is now that password/phrase/key is stored on the client.. the client is the most insecure part of this whole process. 99% of people that end up being vulnerable when this stuff happens run windows. windows without a bunch of work is normally easy to break into. Now were back at the password manager issue we had a few years ago, Are the keys encrypted on the client side still requiring a password to unencrypt? that may mitigate this area i worry about. If not its no better than sending the plaintext password across the internet. botnets are everywhere and everywhen. they scan large, and i mean LARGE chunks of the internet with 0day exploits. then you also have the drive by web attacks. and well we can go on for days on that part. I feel what you have showed me helps, but only moves the risk to the less secure side of the equation.
So essentially after ~30(?) years HTML is still shitty. I kindof figured that from the other posts. Maybe browsers could implement the rolling hashing portion of the deal, allowing the rest of those fields to be fulfilled. There has to be safer ways to do this. Sending plaintext passwords to anybody is a bad idea honestly. Negligence like this is the main reason, a lot of us have known this but your information isnt safe outside of your own network..
if HTML isnt able to securely hash multiple algorithms by now, they need better devs.
youre looking at it wrong, the employees that had access to that log probably had access to that whole site. they could do whatever they wanted with your information you have stored there whether there was a password or not. now $randomhacker gets ahold of that log, and starts testing user pass combos on other sites.. with a pre hashed password.. he gets nothing. with the plaintext password sent from $pleb1 used on $site1-12 $randomhacker gets $popularsite2-4 login information for $pleb1. make any more sense what im talking about.. minimize risk during breeches. because the breeches are going to happen, too much new development on the internet to not happen. you cant secure from thousands of changes a day.
there is a difference between a user password, and a salted hash. one is safer than another to transmit. and they can both be re hashed on the other side, it just becomes less exposing to do it one way and not another, also prevents a breech in one service from effecting another unless its a source copy.
So your password is 'hunter2', and clientside, you hash that to 'asdflkjh1234poiu'. That still has to be sent back to the server, and the server has to validate it somehow. Congrats, your password is now 'asdflkjh1234poiu'. It doesn't matter that I don't know that you typed in 'hunter2' to get to 'asdflkjh1234poiu', all I care about is that if I send 'asdflkjh1234poiu' down the wire in the password field with username 'Highdude702', the server lets me in. I don't care that your password is 'hunter2' and not 'asdflkjh1234poiu', I care about accessing your account.
Ok so as someone has already stated.
if you did use client-side hashing in the first place, and only stored a one-way hash of the already hashed&salted password, you could indeed consider 'asdflkjh1234poiu' your password - TO ACCESS THIS ONE SPECIFIC SERVICE (Twitter). There would however never have been such massive headlines of a leak, because users' plaintext passwords - that they use in many different services - would not have been leaked.
Thanks AC
Now, Like he says.. YOU dont have my real password for one. but whats stopping the server from then hashing the hash I send if they think theyre going to get hacked? I dont understand why you guys are throwing the baby out with the bath water.. I dont give a fuck if someone gets a salted hash of my password. because they have no fucking idea what my real password is. also there is no chance of them doing the apparently common thing of storing it in clear text(i say its common because if you try to claim it isnt then you havent actually been paying attention) It is INSECURE to send YOUR password in clear text to any service or server.. Why does sending the plaintext password become more secure than not sending it? I dont get it. Nobody has been able to explain to me how somebody gets my actual password the way i suggest doing it. the way thats common to do it today. well there are databases with billions of passwords for everybody to see thanks to it.
Ok, first stop using MD5? that sounds like a start. second, encypted session(lets get as secure as we can before we do any auth) server says who are you, client says im John Smith. Server says how do you expect me to believe you, here is an algorithm.. the same as the one you signed up with(you can even do a rolling algo with a flag in the database per user) also heres a salt to use. client says, second mate i need to run this shit quick ill get back with you in a second. client hashes, sends hash over encrypted channel. server responds, ahh Hello John! Welcome.. or it says OI FUCK YOU CUNT YOURE NOT JOHN GTFO! idk its early im sober. seems more secure than sending plaintext secrets over any protocol, encrypted or not. I dont understand what is so insecure about this, that makes sending the plaintext password more secure using the same methods.. it just doesnt seem like people are thinking before they type. i have literally been called a moron because i suggest sending a hash in place of the plaintext password. like someone is gonna read the hash.. but some how would not have been able to read the plain text password. I by no means have a formal education in security, but i have been in the "streets" of the internet since i was a kid and ive seen just about every type of security broken at some point. its not a matter of IF its WHEN. So we need to try to secure as much as possible before that happens. and to me that means my plaintext password never leaves my NIC. Looking forward to your reply.
lmao, me too cause that was a good one.
I would rather someone have a SALTED hash than a plaintext password.
so why cant that string be a common hash, sent to server side for further "secure" as you claim hashing? And I'm the moron.
Look at the user base, and staff.. Twirrer is popular for Trump, Botnets, and Spam.
Hash client side. 1 password isn't going to take long no matter the algorithm.
The plain text passwords should never have been transferred to their servers, whether its through TLS or not.
If they did that little hashing number client side, its never even a thought let alone a problem.
Yes, only the ones that actually use the service and log in.
I'm sure he means Client Side not Server Side, so the only thing transfered is a salted hash.
But honestly, This should be handled client side not server side. that plaintext password should never be sent over HTTPS even, I haven't played with web development in about 20 years, so I cant say how easy this is to do. But I can say that if its not easy to do in HTML/CSS/PHP/Whatever is used, there is something wrong with the language and it should probably never be used for secure access to anything. Just my 2 pennies worth.
I stand corrected sir. Thank you!