Show HN: Login with HN (Unofficially)
loginwithhn.com
loginwithhn.com
Suggestion: on the "Put the token below in your HackerNews Profile" page, rather than polling to see if the token has been added (which is a bit rude) add a button for "I have added this token to my profile" and only check once the user clicks that button.
https://observablehq.com/@endpointservices/login-with-commen...
all code is ISC licensed and both the server and client is embedded in a web notebook
I have vague memories of thinking through how scraping could be used for much easier global authentication and then quickly how that was probably a dumb idea.
:wave: other goon, hope you and all are well.
wallet being on whatever chain(s) decided upon as ubiquitous in the coming year.
https://www.microsoft.com/en-us/security/business/identity-a...
[0] http://zacstewart.com/2012/12/24/verifying-minecraft-user-ac...
DKIM
Let's Encrypt Certificates
Yeah I was worried about this too, it's a disturbing trend.
Venmo was asking for my bank password a couple months ago, I was like fuck no. Who the HELL does that. Should be illegal to even ask.
Doubly fuck no.
Venmo could also get the credentials if they want to, since they're launching it from within their own app. They could keylog everything in their app if they wanted to, including what happens inside Plaid.
Nobody should ask for passwords to anything but their own service. Period.
Asking for bank passwords should be made illegal. If I were the president I would have made that a federal law yesterday.
Plaid provides a useful service that's a stop gap for the poor infrastructure of banks. I honestly doubt that most banks would have even bothered to start the laborious process of OAuth without them being an extremely popular middle layer for services like YNAB. My company actually uses them to process recurring payments.
Plaid is not useful if they need to ask for passwords.
That doesn't mean you should trust them (I don't), but just because you haven't heard of them doesn't mean they're not big.
https://twitter.com/simonw/status/1479174549266526209
Short version: OAuth for banks is finally starting to happen, but in the meantime the password anti-pattern fills the gap.
I have a side project I've been kicking around for a while that required some kind of reputation/login/accountability function and this was exactly what I considered doing: giving people a token to put into a public HN profile.
So anyway, great job Victor!
I wanted to be able to make apps that do social login with HN so I hacked it together.
It works like you would expect -- generating a code you can put in your profile. For convenience, you can then use either TOTP or Email (if you specify both, it will default to using TOTP) to login thereafter to make things quicker (it can take up to a minute until profiles update).
I generally wait about 5 seconds between checks of a profile, hopefully this isn't too much additional strain (especially since I expect most people to switch to something faster after the first login).
[EDIT] Also it's night time (well morning I guess) where I am so... spinning up some more instances and I'm going to sleep.
[EDIT2] My email is plastered all over the site, but please feel free to email me any bug reports!
[EDIT3] If you'd like to register an app, please check out https://mailing-list.vadosware.io/subscription/form ! Ignore all the other mailing list stuff and get on the "early adopters" list for LoginWithHN! Or just email me in my HN profile, whichever!
I guess at this point it's more like login with loginwithhn?
If you're scraping HN, please wait 30 seconds (https://news.ycombinator.com/robots.txt) - our app server still runs on a single core, so we don't have a lot of performance to spare. (Hopefully that will change this year.)
If you need to check more frequently, https://github.com/HackerNews/API works fine and you can get JSON that way anyhow.
export const DEFAULT_HN_POLL_DELAY_MS = "30000";
export const DEFAULT_HN_POLL_MAX_CHECKS = 10;
The code isn't F/OSS but I hope you can take my word on this, worst case what happens is that someone launches two intervals (I don't have any locking on that side) due to hitting two different machines.I'll be switching to the API by the end today and worst case by the weekend.
[EDIT] Forgot to add this -- hope I didn't cause any disruption on your end. thanks for all the hard work as always.
[1] https://firebase.google.com/docs/libraries#client-sdks
[2] https://hacker-news.firebaseio.com/v0/user/hardwaresofton/ab...
Lightweight, low assurance credentials probably have the biggest growth future, as if universal high assurance credentials were really that commercially desirable, we'd already have them. These are a kind of affinity credential, which has a lot of optionality.
A better technical solution would be to offer an SDK that does the same thing that websites could integrate themselves, but then you have the explosion of languages and frameworks to support.
If you affinity federate to HN, (or even a subreddit), and you create a recovery process that enables the user to migrate their local identity on our app to a new IDP, realistically, you could just federate to anything someone can store a key on, if you wanted to. The security of the users account is up to the user.
If I want to bind my user account on your SaaS app to anything persistent online that I have control of, that should be sufficient for most low assurance purposes.
The lightweight security of it is that if I enroll/register for your app as motohagio@location.public_key, my password for your site becomes just a random string encrypted with my private key, as that proves my possession of the private complement used for registration when you decrypt the string using the contents of the public key location I provided during enrollment. A lot of protocols already essentially look something like this, they're just not described in a casual comment.
The lightweight security of the system isn't based on the secrecy of passwords, but rather, a combination of the secrecy of the users private key and the integrity of the registration pointer to that public key. It still works with browser passwords, as instead of a password string, you submit {randomstring, (randomstring)^privkey_privkey} and the RP app just looks up its registered public key pointer, and makes sure the random string in the ciphertext matches.
Problem it solves is net-net it shifts risk off your service, onto the user, and removes a single point of user compromise for all users at once. You can federate your service to any document on the internet that persists a public key, and account compromises don't scale the same way.
The most obvious vulnerability is the integrity and availability of the location and directory services of that public key location. But cacheing and recovery schemes could make it viable. (some people will be apopleptic at the mere mention of it, but it's a use case for the chains made of block)
I've done the high assurance use case design on a variety of other products, but maybe the low assurance case is the one that's actually useful. Irony is it may still require a password manager / authenticator client for most users, but in the majority of logins, you can still save this new token in your browser as a password.
>[...]
>LoginWithHN generates a unique one-time-use code that the user must then put into their profile within 5 minutes
I like the implementation, but shouldn't the code be something more explicit? Otherwise it might be easy to social engineer someone into putting in the code. Currently it's
>Put the token below in your HackerNews Profile ↗
>[random letters]
I think Keybase does something more explicit, with something like "my keybase verification code is xyz"
An attacker site pretends to have their own "Login with HN" implementation, but asks users to put in a code generated from LoginWithHN.com itself.
If the user adds the code, then the attacker can impersonate the victim on any service that supports LoginWithHN.com (because of the special second-time login handling)
If the string was more explicit that it's for LoginWithHN.com, the victim is more likely to recognize that something phishy is going on.
It would be great if this could somehow verify whether an HN account has been part of YC cohort. A few requests we've received were with the hope of offering early access to YC founders-only before a public release.
Also, I love the OTP solution instead of asking for our HN passwords.
Also we verify very similarly to you: https://badge.orangedao.xyz/
If you’re interested to join Ory, we’d be excited to have you! Drop Aeneas a line and he’ll take it from there: aeneas@ory.sh
Hopefully we’ll talk soon :)
Is there a gui in your plans, or a public repo? I want to contribute.
The fact that the admins of this site do manual recovery for example is a terrible practice that no serious providers do. In fact the reason i'm 'AnotherGoodName' rather than my old AReallyGoodName is because i suffered account takeover on this site. The last three posts from AReallyGoodName promoting CoinRace are not me. The rest, including posts for my github projects (i still own my Github) are. https://news.ycombinator.com/item?id=16460663#16461236
I do not think for one second that Hackernews is ready to handle sign ins for things that need more security than this site itself.
[EDIT] I added another disclaimer
Agreed that you added "unoffically", but you also created a new method todo login (vs cookies/oauth2/etc), so I wasn't sure how to map the "unoffically" word with your novel approach. Your disclamer makes it very clear. :)
There have been plenty of horror stories of people that lose access to their Google or Facebook account, and suddenly cannot access their connected accounts.
Nice.
Do you have any sites that support the flow yet?
https://mailing-list.vadosware.io/subscription/form
(Ignore the mailing list bit). If you're able to log in there's a more direct form at the end of the flow!
The author is saying "Yes, I know I've built something that's not very useful here"
[EDIT] - OK just pushed a new version -- it looks like it was a load issue, were you able to get in?
[EDIT2] - Welp, looks like sleep isn't happening, looks like it's load triggered but there are some failures happening... I don't like this hug.
[EDIT3] - We got 'em boys. Found the bug, rolling out now.
Have you ran into this? If so, how did you get around it?
[Edit] Here is a link to the now dead project :( http://web.archive.org/web/20161225152153/http://www.clap.ch... We briefly mention how it worked but didn't go into full detail
There is a trick to busting the cache but I almost don't want to say it in case they fix it lol. Feel free to contact me directly.
One suggested feature that crossed my mind is to allow a minimum karma or account tenure requirement, in order to screen for throwaway accounts in cases where this mattered.
I've always thought that this is a neat idea and similar methods could be used to make all kinds of cross-account connection stuff work on various websites. if you're making any kind of social site like this, allow users to have an editable public bio!
The use case was stealing the userbase from a stagnant competitor allowing everyone to keep their existing usernames on my platform.
Or a more trusty solution is to make the identity verifiable. Oh, did I say Keybase(the former one not acquired by Zoom)?
I'm not sure I fully understood your idea but setting this was exceedingly easy with the help of ORY Hydra[0], please check em out.
If you’re referring more to the possibility of you owning the site itself that’s possible too
To the author, there is a simple trick you can pull in order to make the confirmation instantaneous and avoid caching. Have you figured it out? Let me know!
I also use a residential proxy service for all my profile requests, regardless of the identity provider. For some sites like Twitter, Facebook, etc. this is required, and for something like Hacker News it's simply future-proofing in case they decide to block scrapers at some point in the future.
Good work!
Why are you scraping? We have an API, it's linked at the bottom of every page[0].
To be fair the API's cache invalidation does seem to have improved since last time I tested it. It only takes up to 5-10 seconds now, but still this is an eternity to an impatient user.
Also since you imply you work for HN, I'll give you my little secret: If you randomly capitalize the letters in the HN username it invalidates the cache. Otherwise scraping the profile would indeed take as long as the API approach. I'm taking a risk with you fixing it now. :)
I hope that helps clarify and I look forward to your thoughts.
I was a bit worried that what I was doing was against the spirit of HN (HN is very much not a social site in that way, and I think they strive not to be), but if they ever choose to add native 2FA I'll be over the moon.
``` {"status":"success","data":{"confirmed":false}} ```
Then a failure with a 502, I'll check it on a different network tomorrow to see if it's on my end
[Nest] 41 - 01/14/2022, 2:46:01 AM DEBUG [V1HNController] received polling status request for display token [E7tvuXJkkt]
[Nest] 41 - 01/14/2022, 2:46:06 AM ERROR [LoginService] Error occurred while checking for HN profile page update: Error: Exceeded max checks [10] (delayMs: 30000)
[Nest] 41 - 01/14/2022, 2:46:11 AM DEBUG [V1HNController] received polling status request for display token [E7tvuXJkkt]
[Nest] 41 - 01/14/2022, 2:46:36 AM DEBUG [V1HNController] received polling status request for display token [E7tvuXJkkt]
[Nest] 41 - 01/14/2022, 2:46:42 AM DEBUG [V1HNController] received polling status request for display token [E7tvuXJkkt]
[Nest] 41 - 01/14/2022, 2:46:51 AM DEBUG [V1HNController] received polling status request for display token [unNyaItKHU]
[Nest] 41 - 01/14/2022, 2:47:20 AM DEBUG [V1HNController] received polling status request for display token [e4DMemS2HG]
[Nest] 41 - 01/14/2022, 2:47:30 AM DEBUG [V1HNController] received polling status request for display token [62553gB7GW]
[Nest] 41 - 01/14/2022, 2:47:48 AM DEBUG [V1HNController] received polling status request for display token [unNyaItKHU]
[Nest] 41 - 01/14/2022, 2:47:57 AM DEBUG [V1HNController] received polling status request for display token [dcKr3LelxA]
[Nest] 41 - 01/14/2022, 2:48:22 AM DEBUG [V1HNController] received polling status request for display token [dcKr3LelxA]
[Nest] 41 - 01/14/2022, 2:48:37 AM DEBUG [V1HNController] received polling status request for display token [dcKr3LelxA]
[Nest] 41 - 01/14/2022, 2:48:52 AM DEBUG [V1HNController] received polling status request for display token [dcKr3LelxA]
[Nest] 41 - 01/14/2022, 2:49:15 AM DEBUG [V1HNController] received polling status request for display token [e4DMemS2HG]
[Nest] 41 - 01/14/2022, 2:49:22 AM DEBUG [V1ConsentController] retrieving data for consent challenge request [<redacted>]
[Nest] 41 - 01/14/2022, 2:49:22 AM DEBUG [V1ConsentController] successful consent denial for user [hardwaresofton]
[Nest] 41 - 01/14/2022, 2:50:30 AM DEBUG [V1HNController] received polling status request for display token [62553gB7GW]
[Nest] 41 - 01/14/2022, 2:50:50 AM DEBUG [V1HNController] received polling status request for display token [ZAvILvhGhg]
[Nest] 41 - 01/14/2022, 2:50:58 AM DEBUG [V1HNController] received polling status request for display token [unNyaItKHU]
[Nest] 41 - 01/14/2022, 2:51:49 AM DEBUG [V1HNController] received polling status request for display token [qy4LrME0ny]
[Nest] 41 - 01/14/2022, 2:52:24 AM DEBUG [V1LoginController] received start login request [zzc]
[Nest] 41 - 01/14/2022, 2:52:24 AM DEBUG [V1LoginController] saved login request challenge with ID [<redacted>]
[Nest] 41 - 01/14/2022, 2:52:26 AM DEBUG [V1HNController] received polling status request for display token [lBEUPtqdVF]
[Nest] 41 - 01/14/2022, 2:52:30 AM DEBUG [V1HNController] received polling status request for display token [62553gB7GW
Really appreciate you trying again -- I just did it myself and it was a long ~1min but it did work (in fact you can see me deny the consent actually in the logs :).And for the keen in here, yeah I'm running NestJS[0] -- this thing is over-engineered and some bugs still snuck through.
I've wondered how well it would work on a forum like HN, both for account authentication (making the forum simpler by not requiring passwords) and for identity validation when necessary (for example, highlighting the owner of a project or site.)
I love how minimal HN is and I don't think I've ever seen orange work this well on a site in my life to be honest, so I wanted to pay a little homage and also have people feel at home.
I'll definitely consider changing the theme, and I've already added a disclaimer.