Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sending spammers to password purgatory

troyhunt.com

Post reply on HN
Print view View original

141–150 of 170 posts

Re: Sending spammers to password purgatory

#141

Post by dingleberry420 »

fjfbsufhdvfy wrote: post #109
dingleberry420 wrote: post #100

Earlier quoted context omitted.

So you don't believe in guilty until proven innocent? Or do you? How do you justify banning innocent users?

It really depends on the scale of the punishment doesn't it? Got sent to the gulag - well now you have a major problem. Can't post meme on reddit - oh no! Websites generally aren't obligated to accept all users, precisely because we as a society decided that it's not really a big deal if you can't.

Can't post a meme on facebook - oh no!

Can't access facebook marketplace - legitimately annoying!

Can't access your mail archive going back a decade - could be a huge problem for some people

Sure, it's not as bad as getting sent to the gulag. But the problem with most of these tech companies is far bigger than not being able to post a meme.

Re: Sending spammers to password purgatory

#142

Post by jwozn »

kaiusbrantlee wrote: post #108

This will work on some spammers but not forever. This is an infinite cat and mouse game. For better or for worse, "publicizing spammers pain for our pleasure" has a guaranteed effect of shortening the useful lifespan of this tool. Unless of course no spammers ever read that article, OR HN.

These spammers also aren't aware of Troy Hunt, otherwise they likely wouldn't try to spam him in the first place.

Re: Sending spammers to password purgatory

#143

Post by numlock86 »

brightball wrote: post #120
numlock86 wrote: post #105

Earlier quoted context omitted.

Yes, you are right. No way for a dating site for example (as stated by the original comment) to make a relation between an IP address and the person behind it. It's all fake profiles or some other strawman argument anyway, right? Like who uses his real name, address or even picture for something like that?! That'd be just ridiculous ...

Even with all that, the IP address itself still doesn't represent a person in the hands of that dating site. An ISP can identify which IP address has been assigned to your phone, at what time, on what tower and exactly what points in time that IP addressed changed. It can also associate the device itself with the IP address. An IP address on a cable modem can be associated with a particular account for a house or a b…

Oh okay, so you are a lawyer? My condolences.

Re: Sending spammers to password purgatory

#144

Post by tialaramex »

detaro wrote: post #130
tialaramex wrote: post #126

Earlier quoted context omitted.

When people downvote something I wrote because it's sharing an opinion they don't like it, I kinda get it, that's not really what HN downvotes are for, but sure. However in cases like this what I wrote was just a fact about a world which they weren't aware of, I'm not sure what they hope to achieve by downvoting. ivanbakel wrote "In order for password security to work, you have to send Steam your actual password" and…

It seems pretty obvious that you were downvoted primarily for the entire entirely unnecessary "5 year olds copy-pasting from stack overflow" bit. "Actually, this isn't true anymore, a few years ago [afaik OPAQUE is from only 2018?) they found a protocol that solves this:" would've been a much more productive start to that comment.

While OPAQUE is modern, this whole idea isn't. SRP is a 1997 Stanford project with their results first published in 1998.

But you're probably not wrong about people not liking how I phrased my reply.

Re: Sending spammers to password purgatory

#145

Post by marcosdumay »

GekkePrutser wrote: post #80
alpaca128 wrote: post #55

Earlier quoted context omitted.

Twitch complained that my password longer than 16 characters exceeded the 40 character limit. But the worst I've seen was a registration form that truncates long passwords to the (hidden) maximum length of ~10 without telling you, so anyone choosing a safe password cannot login and won't know why.

Vnc does this too with it's 8 characters. Stupid design decision. Even more stupid though is their declaration that encryption is 'out of scope' and anyone wanting it should arrange it out of band (eg VPN or SSH forwarding). Seriously... :/

Well, given their track history, they are very correct on their recommendation to allow localhost connections only and tunnel any traffic through ssh. I mean, would you trust them to enforce the security of their server?

(It would be better if they only allowed pipeline connections and actually required that you run the data through ssh. But I bet they didn't notice people have all kinds of untrusted software running on localhost.)

Re: Sending spammers to password purgatory

#146

Post by GekkePrutser »

marcosdumay wrote: post #145
GekkePrutser wrote: post #80

Earlier quoted context omitted.

Vnc does this too with it's 8 characters. Stupid design decision. Even more stupid though is their declaration that encryption is 'out of scope' and anyone wanting it should arrange it out of band (eg VPN or SSH forwarding). Seriously... :/

Well, given their track history, they are very correct on their recommendation to allow localhost connections only and tunnel any traffic through ssh. I mean, would you trust them to enforce the security of their server? (It would be better if they only allowed pipeline connections and actually required that you run the data through ssh. But I bet they didn't notice people have all kinds of untrusted software running…

I agree with that recommendation (it's absolutely not advisable to expose it to the internet even if it were encrypted) but that's where defense in depth comes in.

It's not supposed to be the only level of security but using unencrypted protocols in this day and age for something as sensitive as server control is unforgivable.

For example tunneling through SSH does make it possible for other people to sniff the traffic on either side if they are on localhost. Port forwarding is not a very safe tech since it doesn't allow to limit which user uses the port.

Re: Sending spammers to password purgatory

#147

Post by ivanbakel »

tialaramex wrote: post #126
tialaramex wrote: post #94

Earlier quoted context omitted.

No. In order for password authentication to be something a five year old can do by pasting PHP code they found in a Stack Overflow search, that is how it works. But algorithmically even if you want passwords (you don't in most cases, get WebAuthn for example for web site authentication) you can use an asymmetric PAKE such as OPAQUE: https://tools.ietf.org/id/draft-krawczyk-cfrg-opaque-03.html This is quite a bit more…

When people downvote something I wrote because it's sharing an opinion they don't like it, I kinda get it, that's not really what HN downvotes are for, but sure. However in cases like this what I wrote was just a fact about a world which they weren't aware of, I'm not sure what they hope to achieve by downvoting. ivanbakel wrote "In order for password security to work, you have to send Steam your actual password" and…

To quote the guidelines:

>Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

Re: Sending spammers to password purgatory

#148

Post by ivanbakel »

archi42 wrote: post #115
ivanbakel wrote: post #107

Earlier quoted context omitted.

You're just adding a step for generating the hash-as-password from some other information. Just because you label something in that generation step the "password" doesn't mean you're avoiding the hash being the password. From your and Steam's perspectives, "X" is still a secure value that Steam has to see in plaintext and not store.

I simplified my other post for better readability and just realized I made a stupid mistake doing so; I replaced a public per-user salt that's to be queried during login with "normalize(username)". In the given variant it would actually be possible to perform credential stuffing if both use exactly the same hash function and if I use the exact same username. However, if a user-specific (or at least site-specific) pub…

To me, you're overthinking the original comment. The particular line

>Also, steam should never even see the password, they should only ever see the hash.

is, if you interpret it generously, trivially true. There are 101 authentication mechanisms where Steam doesn't "need" to see a password (i.e. some secret information that is remembered by the user.) As you point out, the password can be hashed and even salted before transmission.

Alternatively, Steam could authenticate with e.g. a public/private keypair, in a way that means that it would be immune to replays of the authenication protocol, while never seeing or storing any sensitive info.

But I find it hard to believe that the original commenter's objection to Steam seeing your password is based on any of these alternatives. The comment didn't say "Steam should be using a protocol where they don't see your password", and I don't think many hackers have such an opinion about any service, given how prolific just basic username+password authentication is on the web.

My original reply was based on the interpretation that the commenter had misunderstood how username+password authentication interacted with password hashing, both of which are technologies used in 99.99% of web services - rather than a more esoteric approach which somehow justifies the idea that "Steam shouldn't see your password".

Re: Sending spammers to password purgatory

#149

Post by jakzurr »

legalcorrection wrote: post #16

This is wrong. You are logging their password attempts and then sharing them with the world. It doesn’t matter that you think you know they are scammers. What gives you the right to dispense vigilante justice by disclosing people’s passwords? Shame on you.

Thanks for your post. I enjoyed it so much I almost up-voted it.

Re: Sending spammers to password purgatory

#150

Post by marcosdumay »

GekkePrutser wrote: post #146
marcosdumay wrote: post #145

Earlier quoted context omitted.

Well, given their track history, they are very correct on their recommendation to allow localhost connections only and tunnel any traffic through ssh. I mean, would you trust them to enforce the security of their server? (It would be better if they only allowed pipeline connections and actually required that you run the data through ssh. But I bet they didn't notice people have all kinds of untrusted software running…

I agree with that recommendation (it's absolutely not advisable to expose it to the internet even if it were encrypted) but that's where defense in depth comes in. It's not supposed to be the only level of security but using unencrypted protocols in this day and age for something as sensitive as server control is unforgivable. For example tunneling through SSH does make it possible for other people to sniff the traff…

I do respect people that say "I don't know how and don't want to learn how to solve this hard problem, so I'm letting it explicitly unsolved", as long as that "explicitly" is part is real.

And yeah, I would probably use vnc if the protocol was over a pipeline, like scp or rsync. As it is now, it's a program to avoid.

Defense in depth is only useful for vulnerabilities that you can't solve to a satisfactory level. You should be able to publish a high-quality access server on the internet without any loss of security.

Post reply on HN