Sending spammers to password purgatory(troyhunt.com) |
Sending spammers to password purgatory(troyhunt.com) |
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
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.
Spammer burned a total of 80 seconds in Password Purgatory
spam is orthogonal to legality
they're still spammers, though, and yeah, I totally think they deserve this
Yes
We'll manually review all accounts that use (more than one of) those ip addresses. Works like a charm! :-)
This makes all the difference with other services that block out users only to let them guess why they were blocked.
If an automated system did that, I would have said it's evil. Yet, I hope you have a communication channel in case there was a human error.
If you can afford to get the FPR down, sure, have fun, but if not, please have the decency to not pretend.
And how would the legitimate owner of that IP address ever know how to contact you to get removed from your blacklist?
Legitimate users would be able to contact us using the email address that is shown right underneath the error message.
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 have some step fail or reach a dead end. They really seem like they're just set up to intentionally waste people's time.
For example, Steam has a system where if you enter too many invalid passwords, it will present you with a captcha which you can never actually solve. It's a lot more annoying than just saying "you have been locked out of trying to log in for X hours".
But this, this is fine. It's pretty clear that the person you're targeting is a spammer, and it's pretty clear to the user after about 60 seconds that you're password system is a joke.
I call this "login gaslighting" and it's evil. Pioneered by the "do no evil" company.
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-malicious user gets caught in one of these traps...
Sounds like something a film villain would say when asked about collateral damage.
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!!!")
Lasted a few hours. I figure someone else on that vpn was doing something wrong and they just blocked anyone from there for a while.
Super frustrating that your left to just … to get frustrated.
Figure it was a mistake from some automated security framework type of deal.
But how many people do I know born in 88. Or on the 8th of August?
I understand that given the login is your public visible name on steam they just don't want clear neo-Nazi signifiers.
Edit: Typo
'Password must contain at least 1 primary Simpsons family character'
'Password must contain at least 1 Nordic character'
'Password must contain at least 1 Greek character'
'Password must contain at least 1 primary Griffin family character'
'Password must contain at least one emoticon'
'Password when stripped of non-numeric characters must be a number divisible by 3'
[1] https://github.com/troyhunt/password-purgatory-api/blob/mast...
Having the conditions contradict each other serves as a proof that it’s impossible to create a password; I thought this information shouldn’t be revealed to the user.
Looks like there is already an issue about it: https://github.com/troyhunt/password-purgatory-api/issues/45
Edit: I just noticed the list has one requirement for an emoticon, and another for an emoji. Carry on.
I did the same thing 10 years ago and it was one of the best morale builders for our team after all the time we spent dealing with these folks.
https://www.brightball.com/articles/waste-spammers-time-to-r...
So I pick up spam calls, press 1 immediately, then put the phone back in my pocket. This usually connects it to a real person who hears ambient noise, thinking I'm nearby. Usually I waste like 60sec of their time for 2sec of my time. It's hard for them to protect against this because no matter what, they need some victims to talk to the real person, unless they develop a very smart AI. But a relatively simple bot with a list of likely scam numbers could automate the fake victim's side.
A colleague was dealing with more advanced scammers who had already made some progress with his unaware mother. Their scam was unique in that it required calling them back. He managed to collect all the phone numbers they were using, then he put up fake Craigslist ads for free couches... and you can guess the rest.
The Craigslist trick worked because of a unique situation. They were using real numbers because their scam relied on being called back. He did call manually to make sure.
Believable, stupid requirements I've seen in the wild in the bad early days of complexity requirements.
- your password contains a common word
- your password contains one or more repeating characters
- your password contains a forbidden character
- your password needs at least one additional uppercase letter
- your password needs at least one more distinct special character
- your password cannot end with a special character
- your password contains an escalating series of numbers
- your password is too short
- your password is too long
Original title in full is: Sending Spammers to Password Purgatory with Microsoft Power Automate and Cloudflare Workers KV
Don't do that. No, really, don't.
Okay, you didn't listen and did it anyway; please, at least don't automate it or semi-automate it where you're just doing it with one click.
> Spammer burned a total of 80 seconds in Password Purgatory
So you think, based on the belief that when you reply to the spam, it goes back to the spammer.
That may not be the case; when you engage spam, you are possibly generating "backscatter"; a person having nothing to do with the spammer may receive the e-mail.
Spam messages are not always relying on someone replying to them to hook in the victim. Sometimes there is no hook at all, or sometimes the hook is in the HTML links, and not in replying. (They additionally hope that if you reply, the person you are replying to will also get the spam e-mail, since it is quoted, and that person will click on the links.)
My own low-effort method is to accept mail for any domain on my name servers. Spammers think they are relaying their scams but it just goes to a flat text file. It isn't like I try to hide it. The banner even says its a honeypot and not to use it.
139K /var/spool/mail/vhosts/crap
24K /var/spool/mail/vhosts/crap
177K /var/spool/mail/vhosts/crap
196K /var/spool/mail/vhosts/crap
They’re not typically trying to get you to reply - they’re trying to get you to click a link.
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 erroneous.
Or you could make a "check your input one more time before confirming" step and display typos in e.g. names/emails there.
1. marcopollo – Password must contain at least two numbers. 2. marcopollo11 – Password must not begin or end with a number. 3. m1arcopoll1o – Password must not contain two of the same number. 4. m1arcopoll2o – Password must contain at least one special character (! ? & % $ # @). 5. m1arcopoll2o! – Password must not end with a special character. 5. m1arcopoll2!o - Password must not contain 3 or more of the same letter. 6. m1arcopoll2p! - Password must not contain 2 of the same consecutive character. 7. I forget, but it kept going.
At some point, I gave up and started generating random passwords. The first 3 attempts were still not accepted. In a way, those restrictions were actually reducing the entropy.
- Arrive, Raise Hell, Leave
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.
1. Ask for a username, only offer "OK"
2. Upon OK: Wait 2-3s while showing an ajax spinner, then add another box to the DOM, asking for an "e-mail"
3. Rinse and repeat with first name + last name; then company name; country (pick from a list of ~50 widely known country names, sorted by median age of the population - remove the IPs country of origin, so they have to pick "other" and enter it manually)
4. Tell the user the username doesn't match the expected format and offer to add a random "#1234" for them - upon doing so, back to square one (except their username is now "#1234" and not "scamoverlord#1234"). make sure to flush the other info as well.
5.1. Tell them you're sending a verification mail (you don't). Offer them to resent it after 30s.
5.2. Upon "try again", tell them first to check their mail address, and lock the "try again" for another 10s.
5.3. Now, after another 30s, tell them there must be an error with the mail gateway (there is no mail gateway) and offer them to continue; the verification mail is queued and will be sent later (-> you're sooo super userfriendly!).
6. Now the user/victim easily spent 90s to enter "valid" details and must be quite invested. Show a re-captcha style captcha before asking for password (after sending an email and possibly spamming someone? yeah, maybe put that before the fake mail verification, I came up with that in the wrong order).
7. the "checking if you're human" should fail after 3-4s (spammers are used to that).
8. Then the first of the 9 captcha images should pop up afer 1-2s initial "loading time", the other ones after another .5 - 2s, each.
9. Let the first one or two captchas fail no matter what (two if they're fast, one if they're already spending a lot of time there - plausible if you're handpick terms + images for which foreign speaker often don't know the exact meaning; like "barnacles", "melange", "cabin", "truck", or showing differnt styles buses and asking for "tram").
10. Three times the charm: Accept any answer, as long as the "user" spent more than 4s on it (use a simple term with obvious images to make it plausible, like "birds" or "cars").
11. finally get started with the password. Let them do four or six levels.
12. What's that, the the captcha timed out and/or too many bad password tries? Are you sure you're not a bot? Well, do it again! (maybe let them only fail once to keep them hooked)
13. Oh no, the password field has been reset after the captcha was solved. At least you now know how to do a rule-abiding password. So let them do all the levels.
14. If they're really persistent, fake a "oh no, your tab crashed, reload?" screen for their browser.
Uuuuh, I think I put that on my infinite todo list.
PS: Have them write "a few words" about their business. Make sure to garble copy/paste (e.g. reverse word order or just reset length counter to 0, increase decrease from there and do a proper recount on submit). On submit, verify the input for a few seconds and claim that it's either to short or too long (if they wrote >500 chars, say it should be 200-400, if they wrote <500 chars, ask for 600-800). And remember to keep the char counter broken (update only after not typing for 2s, making the input field not readable for another second while "counting"). Bonus points if a WYSIWYG editor widget is used, which of course takes 5 to 10s to load; or have a "worker" at Amazon Mechanical Turk review it (only takes 30 to 90s).
PPS, for balls of steel: Add a second act by only enforcing the first few levels. Then, upon login, tell them they need to change their password. Maybe also tell them if they install your "super special" security extension, they can use weaker password rules. If they stupid enough to really install it, let it send a "X-Block-Me: I am a scammer" header along with every http/s request.
I'm sure it's great fun to design and build and occasionally get to watch.
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.
Bitte geben Sie ein sicheres Passwort ein.
Leberkas
Entschuldigung, Ihr Passwort ist zu kurz!
Leberkas-Semme
Entschuldigung, Ihr Passwort muss mindestens 1 Zahl enthalten.
1 Leberkas-Semme
Entschuldigung, Ihr Passwort darf keine Leerzeichen enthalten.
50drecksleberkassemmen
Entschuldigung, Ihr Passwort muss mindestens einen Umlaut enthalten.
50drecksleberkässemmelnzefix
Entschuldigung, Ihr Passwort muss mindestens 1 Grossbuchstaben enthalten.
50DRECKSleberkässemmelnZEFIX
Entschuldigung, Ihr Passwort muss mindestens 1 Sonderzeichen enthalten.
50DRECKSleberkässemmelnZERFIX!!!!!!!
Entschuldigung, Ihr Passwort darf nur Grossbuchstaben enthalten, die nicht aufeinanderfolgend sind.
KreizKruzeFixVerdammterScheissDrecklatzkannstMiGleiKreizWeisSonstWo WoslnDesFiaAScheissSystem50DrecksleberkässemmelnZeFix!!!!
Entschuldigung, dieses Passwort ist bereits in Verwendung. Bitte wählen Sie ein anderes.
Early days? Every sodding week for me....
Dumb Password Rules
Shaming sites with dumb password rules.
Sounds like you never had to actually deal with such a spammer problem yourself
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
In such a situation, I often think: isn't the fact that one makes "stupid mistakes" when attempting to solve a ReCaptcha rather a sign that the entity that is attempting to solve it is a human?
The smug gaslighting and intentional time wasting after an incorrect identification is the worst.
Just having a VPN + private mode is enough. That's how Google pushed me into becoming a happy DDG user.
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... :/
(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.)
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.
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.
Also, steam should never even see the password, they should only ever see the hash.
Sites/apps will generally handle your plaintext password each time you login or set your password. They (hopefully) just don't store it.
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.
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.
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 complicated than the one line PHP password stuff you pasted from Stack Overflow, but the user's password never leaves their machine, and so the Relying Party doesn't know the password, and yet they can verify that the user does know the password which they originally chose for the site.
- https://en.m.wikipedia.org/wiki/Internationalized_domain_nam...
----- 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))
>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".
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 that's not true. It's not going to become more true if you can just delete my comment explaining why it's not true, that's not how our universe works.
But you're probably not wrong about people not liking how I phrased my reply.
>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.