Hacker News Reader

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

I call this "login gaslighting" and it's evil. Pioneered by the "do no evil" company.

ReCaptcha does a similar tactic but rather than unsolvable it's a stream of the most annoying captcha -- "select all of image until none are left". Fail one and you're back at the start. You do have the option to cycle captcha, but 9/10 times it'll be this one. Eventually you'll get locked out of captcha entirely. Anyone who has used Tor on Google has probably experienced this.

The worst cpatcha has got to be Rockstar games support. You have to click all the images of rolled dice that sum up to 13, 5 times in a row. Then another 5 for some reason. If you make one mistake, you go back to 0.

Would it be “Tor on Google” or “Google on Tor” unless you mean you’re running a Tor node on gcp I would think it would be the latter?

> ReCaptcha does a similar tactic but rather than unsolvable it's a stream of the most annoying captcha -- "select all of image until none are left".

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?

I'm sure they build in tolerance and even take advantage of this signal, yes. The result is still far from reliable, though.

The smug gaslighting and intentional time wasting after an incorrect identification is the worst.

> Anyone who has used Tor on Google has probably experienced this.

Just having a VPN + private mode is enough. That's how Google pushed me into becoming a happy DDG user.

So that's what that was... Was trying to do something legit, MS gave me a puzzle to solve, it was unsolvable in the time given, it wasted maybe 20 mins. Can't remember what it was, I think create an account for visual studio (you had to sign in to an MS account to keep using free VS, the wankers).

https://github.com/VSCodium/vscodium

Well, look at that! Thanks

People reports getting much easier puzzles when they use Edge.

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-malicious user gets caught in one of these traps...

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

"Unfortunate"

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

Google had me in an endless no right answers captcha after I left a vpn on one day.

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.

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.

You are lucky. I haven’t been able to use Ticketmaster for 2 years because all IPs from my ISP are blocked as bots. Contacted their support on Twitter and they told me the only way to use their site is to change my ISP as even the VPNs I tried are blocked. Looks like they have enough money to have the luxury to block one of the biggest ISP where I live

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.

Verizon’s site times out your login after like 2 minutes. Just trying to manage my account on the site is a nightmare, and I’m on fiber.

steam censors passwords. if you have 88 in your password you will fail to register

I understand the initial idea to block this known neo-Nazi short handle (8 for the letter H and 88 as HH standing for the 'Heil Hitler' salute in these circles).

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

I bet for every one neo-nazi they block hundreds of birthdays or Chinese [0]. Just seems overly sensitive to me when you wouldn’t even know a person is a neo-nazi unless they start saying neo-nazi shit. Saying neo-nazi shit is in itself grounds for a ban so why block the number 88 at all? How could anyone possibly be offended by the number 88 alone?

0: https://en.wikipedia.org/wiki/Chinese_numerology#Eight

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.

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

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.

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

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

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

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

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.

Somehow I thought OPAQUE had some important change that made it practical compared to previous variants, but now I can't find what that would be or why I thought that, so yeah, the reference to the date is indeed irrelevant I think.

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.

The real fun starts with IDNs -- internationalized domain names.

- https://en.m.wikipedia.org/wiki/Internationalized_domain_nam...

I just made a new steam account with '88' in the password. It seems to have worked fine. I also can't find any reference to this on the internet.

https://www.adl.org/resources/hate-symbol/88

Sorry, you are right. I meant any reference with regards steam passwords.