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

61–70 of 170 posts

Re: Sending spammers to password purgatory

#61

Post by thombat »

shaky-carrousel wrote: post #54
drfuchs wrote: post #22

Troy, watch out you don't open yourself up for an attack from the bad guys: They'll start sending you solicitations with ReplyTo addresses of industry honeypots, and before you know it, you'll become a known spammer and your regular outgoing emails will be routed to recipient's spam folders or maybe even dropped entirely.

I found a surprisingly effective way of detecting honeypots some time ago, while working at an email marketing company.

You have a truly marvelous demonstration of this method, which this margin is too narrow to contain?

Re: Sending spammers to password purgatory

#63

Post by tpoacher »

fjfbsufhdvfy wrote: post #11
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…

They are indeed set up to waste people's time. Blocking people leads to them searching for ways around your block really quickly. Making them waste time not realizing they have been blocked, such as endless retries or shadow bans, is much more effective at making them stop bothering you for a while longer. Time spent doing this is time they can't spend being malicious on your platform. It's unfortunate when a non-mal…

"Unfortunate"

Sounds like something a film villain would say when asked about collateral damage.

Re: Sending spammers to password purgatory

#64

Post by archi42 »

quickthrower2 wrote: post #50
Ueland wrote: post #31

Earlier quoted context omitted.

I'm not sure if you're joking or not so: He already gets attacked from the bad guys.

And this would be a new way to attack him

He's triggering it manually. And I'm pretty sure he knows what backscattering is.

Re: Sending spammers to password purgatory

#65

Post by InCityDreams »

Pxtl wrote: post #13

I assume your starting password rules deliberately set the bar low to encourage PRs to improve it, since I can think of much more believable, infuriating, tedious ways to drag this out longer, keeping the user thinking they're always one step away from a valid password without being obviously silly. Believable, stupid requirements I've seen in the wild in the bad early days of complexity requirements. - your password…

>stupid requirements I've seen in the wild in the bad early days of complexity requirements.

Early days? Every sodding week for me....

Re: Sending spammers to password purgatory

#66

Post by numlock86 »

vanviegen wrote: post #48

For our dating site, which of course has to deal with many prinses, Nigerian or otherwise, when we manually verified an account to be a scammer, we reject logins with a message stating that the IP address has been blocked. Scammers will usually go through all of their VPNs/bots in order to try to login, allowing our system to flag them all. We'll manually review all accounts that use (more than one of) those ip addre…

[flagged]

Re: Sending spammers to password purgatory

#67

Post by Hackbraten »

ImPostingOnHN wrote: post #32
bo1024 wrote: post #10

I wouldn't be comfortable doing this, for one thing, we know people tend to re-use passwords. So any email/password info you collect should be treated with security like they just gave you their bank login, because some of them did. So then Troy has to report himself to his own service (haveibeenpwned).

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.

Re: Sending spammers to password purgatory

#68

Post by Nextgrid »

numlock86 wrote: post #66
vanviegen wrote: post #48

For our dating site, which of course has to deal with many prinses, Nigerian or otherwise, when we manually verified an account to be a scammer, we reject logins with a message stating that the IP address has been blocked. Scammers will usually go through all of their VPNs/bots in order to try to login, allowing our system to flag them all. We'll manually review all accounts that use (more than one of) those ip addre…

[flagged]

Legitimate interest would totally cover you here. The fear-mongering and misinformation about the GDPR is getting really annoying by now.

Re: Sending spammers to password purgatory

#70

Post by archi42 »

ivanbakel wrote: post #59
coffeeblack wrote: post #35

Earlier quoted context omitted.

88 is a lucky number in China and many Asian countries. Maybe time to claim “cultural insensivity” or something? Also, steam should never even see the password, they should only ever see the hash.

If Steam never saw your real password, the hash of the password would itself become the password, and Steam would be storing your password in plaintext. In order for password security to work, you have to send Steam your actual password, which they then check against the hash themselves. So at some point, Steam will have your password in plaintext.

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" authentication hash X on the server either. Yes, a manipulated client can send a stolen X instead of a stolen password (but in reality it's a reused password that's been stolen, not X). The advantage is that a compromised server will then not be able to log the plaintext password for credential stuffing.

In case anyone thinks about using the above scheme: Don't. It's merely an illustration for one specific property. Other than that it is PAINFULLY flawed in many ways.

Post reply on HN