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

111–120 of 170 posts

Re: Sending spammers to password purgatory

#111

Post by marcinzm »

numlock86 wrote: post #105
brightball wrote: post #77

Earlier quoted context omitted.

People can claim it all day long but it was determined that IP addresses are only PII in the hands of an entity who can actually associate it with a person, like an ISP. https://www.jdsupra.com/legalnews/court-confirms-that-ip-add...

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 ...

...you're assuming they're keeping the IP linked to a specific profile and then making a strawman argument based on that assumption.

Re: Sending spammers to password purgatory

#112

Post by roveo »

efitz wrote: post #57

The complexity requirements pretty quickly become unreasonable, to the point that I would have realized they weren’t serious after like the 2nd try. To be really evil, Troy should play with the password field- make it not a text or password field, but rather some sort of custom input field that doesn’t work with password managers and doesn’t allow paste. Also maybe return errors sometimes that are themselves erroneou…

A better idea would be to use custom inputs that produce "typos" that the user didn't make. E.g. you have a "zip/postal" code field and your input sneakily swaps 2 neighbouring characters at some point, resulting in error "this zip code doesn't exist". Or change 8 to 9 etc.

Or you could make a "check your input one more time before confirming" step and display typos in e.g. names/emails there.

Re: Sending spammers to password purgatory

#113

Post by thegrimmest »

dingleberry420 wrote: post #100
raverbashing wrote: post #98

Earlier quoted context omitted.

Yes banning users from a website is exactly like sending them to the gulag, it's exactly that

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

I do believe you're misapplying Blackstone's Formulation. I think it's perfectly fine to presume guilt in some cases when operating a public service. This can be reformulated as making users go through extra steps designed to screen bad actors. We in fact do this at places like airports (and increasingly schools) all the time.

For instance if your user happens to be an unwitting botnet member (or even if he has a newly assigned IP previously belonging to one) - his IP will be suspicious and you can "punish" him accordingly. Also Blackstone's ratio was 1/10, not 1/1000.

Re: Sending spammers to password purgatory

#114

Post by ImPostingOnHN »

legalcorrection wrote: post #110
ImPostingOnHN wrote: post #33

Earlier quoted context omitted.

you are mistaking scammers with spammers, and also mistaking what the poster thinks with reality the reality is they are spammers, because spamming the poster is the only way they can end up with a reply email containing a link with a valid key to interact with this API if they didn't send unsolicited commercial emails, there's no way they can interact with this API and get their passwords logged

This is a common misconception. Cold emailing is legal under the CAN-SPAM Act.

this is a common misconception, unsolicited commercials emails are still spam, whether or not they are legal

spam is orthogonal to legality

Re: Sending spammers to password purgatory

#115

Post by archi42 »

ivanbakel wrote: post #107
archi42 wrote: post #70

Earlier quoted context omitted.

No, not really. I'll give you an example that's not really secure, but should illustrate one possible method: 1. You produce an "authentication hash" X = hash(normalize(your_username) + your_password) and send X to the server. 2. The server computes Y = hash(X) and checks Y against the stored hash. Now you're not sending the plaintext password to the service (e.g. steam), and steam is also not storing the "raw" authe…

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) public salt is added, this doesn't work anymore. That's what I deserve for writing this by heart instead of putting it into ProVerif first. Maybe that bad simplification caused the misunderstanding?

----- edit, original post. feel free to answer if you still disagree :)

Now we're talking labelling. To me the password is what I, as a human, enter in some login form. What's sent to the server is derived from that. In once case the derivation function is just the identity, in the other case it's a trapdoor permutation (with a public salt). For the authentication flow it's quite similar, yes, and for many kinds of attack I wouldn't care what I have (e.g. PtH on Windows) - but for the user there is a huge difference if they memorize + enter "7110eda4d09e062aa5e4a390b0a572ac0d2c0220" or "1234".

Let me pose a scenario and ask you a question: Assume I'm dumb and my login on HN as well as Steam is archi42 with password s3cr3t. Now the simple "sent password in the clear to the server" allows GabeN [president of Valve/Steam] to log my credentials and post spam on HN. With a trapdoor derivation function that's not possible anymore [this is where I realized my bad simplification]. So if the two are exactly the same thing, why does that attack work in once instance, but not the other?

(edit2: if you answer this, assume that there is a user-specific, public "salt" A that the client queries from the server prior to computing X = hash(A + password))

Re: Sending spammers to password purgatory

#116

Post by ImPostingOnHN »

Hackbraten wrote: post #67
ImPostingOnHN wrote: post #32

Earlier quoted context omitted.

the article goes into detail to explain how only spammers have a key to the api which logs that data

They’re still people though. Is punishing spammers for what they’ve done a helpful thing to do? Sure. Are spammers deserving of having their whole digital lives compromised? I don’t know.

"they're still people", indeed I hope so, or else either the animals or the machines are spamming us on their own somehow ;)

they're still spammers, though, and yeah, I totally think they deserve this

Re: Sending spammers to password purgatory

#117

Post by ImPostingOnHN »

raverbashing wrote: post #49
ImPostingOnHN wrote: post #30

Earlier quoted context omitted.

it is unfortunate that some people believe those pros outweigh the punishment inflicted on innocent users it is better a thousand criminals/ spammers go free than a single innocent non-spammer be treated as if they are one essentially the companies are shifting their own pain (with spammers) onto innocent users ("it's your problem now, suck it users, lol!!!")

> better a thousand criminals/ spammers go free than a single innocent non-spammer be treated as if they are one Sounds like you never had to actually deal with such a spammer problem yourself

"its easier to just punish everybody than single out the person actually deserving of punishment" is actually a common defense of collective punishment

the equal and opposite response would be, "Sounds like you never had to actually deal with such a usability problem yourself", but I'm not interested in trying to devolve this discussion into one about you and me, instead of the topic

Re: Sending spammers to password purgatory

#118

Post by 0xFF0123 »

marcinzm wrote: post #111
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 ...

...you're assuming they're keeping the IP linked to a specific profile and then making a strawman argument based on that assumption.

It sounds like that's what they're doing, in order to find other spam accounts: > We'll manually review all accounts that use (more than one of) those ip addresses.

Re: Sending spammers to password purgatory

#119

Post by zerocrates »

___8___ wrote: post #8
armchairhacker wrote: post #5

Ok, I have no issue with tactics like these when they're wasting spammers' time. But sometimes it seems like real users get caught up in these honeypots for scammers and hackers. A lot of the crap real sites make people go through e.g. when they lose access to their account or login to a VPN or the site just "can't verify their identity" for some reason. Where you go through a bunch of hoops and captchas, only to hav…

I tried to sign up for steam and my long complex password seemed to trigger a never ending stream of captures. Also, just today ticketmaster decided my firefox browser was a bot and blocked me. Fun times.

StubHub was just doing the same thing to me: Firefox and only Firefox was blocked entirely.

Figure it was a mistake from some automated security framework type of deal.

Re: Sending spammers to password purgatory

#120

Post by brightball »

numlock86 wrote: post #105
brightball wrote: post #77

Earlier quoted context omitted.

People can claim it all day long but it was determined that IP addresses are only PII in the hands of an entity who can actually associate it with a person, like an ISP. https://www.jdsupra.com/legalnews/court-confirms-that-ip-add...

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 business office, but even it can't positively identify the person in the house or at the business who was using it to connect to a particular website.

And yes, as you said, anybody can create a fake profile. A coworker could create a fake profile on a dating site of you if they wanted to and that IP address still doesn't positively identify you.

The name, address, photo...all of that is absolutely PII and covered by GDPR.

The IP address isn't and is also used for legitimate security purposes. People trying to get them scrubbed under GDPR are overreaching on a piece of data they have no right to have scrubbed.

Post reply on HN