Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Somebody implemented something I wrote a blog about

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 253 posts

Re: Tell HN: Somebody implemented something I wrote a blog about

#111

Post by jbverschoor »

spiffytech wrote: post #28

Years back, every web browser's built-in password manager locked up the page when submitting a login form, waiting for the user to answer "do you want to save this password?" before proceeding. I thought that was silly: how do I know if I want to save the password before I've seen whether it's correct? Which I can't see until the form is submitted. At the time I was using Opera, so I wrote in to their customer suppor…

I submit suggestions, features, bugs, detailed reports, new use cases etc. I'm more than happy to write detailed submissions, or do some traces when there's a bug.

But if I notice there's no feedback or implementation within a reasonable period of time, I will stop doing that ever again for that company (large, small, doesn't matter).

I refuse to waste my energy on that kind of process.

Re: Tell HN: Somebody implemented something I wrote a blog about

#113

Post by unsafecast »

motoxpro wrote: post #109
unsafecast wrote: post #105

Earlier quoted context omitted.

Another thing that bothers me, in Spotify and pretty much everything else: you can't add playlists to other playlists. Like union directories. The most important thing is that it's a link, so every list updates whenever I update the included one. If there's a program with this type of functionality, lmk.

I don't really understand how that is useful but if you need to do it manually you can just shift click all the songs and add them all to a playlist on the desktop app

Yeah, I get why it wouldn't be. I just have a peculiar way to organize my music.

I know I can do that, it just doesn't sync when I change another list, which breaks everything.

Re: Tell HN: Somebody implemented something I wrote a blog about

#116

Post by OinkEsFabuloso »

spiffytech wrote: post #28

Years back, every web browser's built-in password manager locked up the page when submitting a login form, waiting for the user to answer "do you want to save this password?" before proceeding. I thought that was silly: how do I know if I want to save the password before I've seen whether it's correct? Which I can't see until the form is submitted. At the time I was using Opera, so I wrote in to their customer suppor…

Oh, that's so cool! :-) Could you please write to Whatsapp or Telegram and ask them not to delete the EXIF information from shared images on their platform? I understand that they compress images so they don't take too long to transmit and load, but I think there's a big group of their users (especially for Whatsapp) that use their platform to share family pictures. For this purpose, having the EXIF date (if it's available) could be very handy, since the picture could be properly timestamped and archived without having to ask again to the original poster for the specific files.

Re: Tell HN: Somebody implemented something I wrote a blog about

#117

Post by ezekg »

kevincox wrote: post #99
ezekg wrote: post #25

Related: I think it's surprising how many services leak whether or not a password is correct. E.g. bad password => error, good password => 2FA prompt. You should verify a user's second factor before password.

This is technically superior for things like TOTP but falls apart if not all users use TOTP. 1. Users who aren't using 2FA have a confusing box to leave empty. 2. SMS, Email and similar OTP codes should only be sent after the password is verified. 3. U2F requires the site to share which devices are registered which can only be done after the password is verified. You may be able to make it work UX-wise if you separat…

Your login form doesn't need to display an empty second factor input. Your server can send back a specific error code on first login attempt that can be used by the UI to prompt for the user's second factor, whatever that may be (or even give a choice, in the case of multiple second factor types).

For example, given this /login request to our server:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
Depending on the user's second factor, the server could send back a response like this:

    { "error": { "code": "TOTP_REQUIRED" } }
Then, depending on the error code, our UI could prompt for the second factor and we could send a new /login request:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
    { "totp": "123456" }
This flow can work for any type of second factor, not just TOTP. It also works for good and bad passwords, and doesn't leak any information (well, other than the fact the user exists, but that road introduces a lot of other UX issues.)

Re: Tell HN: Somebody implemented something I wrote a blog about

#118

Post by kevincox »

ezekg wrote: post #117
kevincox wrote: post #99

Earlier quoted context omitted.

This is technically superior for things like TOTP but falls apart if not all users use TOTP. 1. Users who aren't using 2FA have a confusing box to leave empty. 2. SMS, Email and similar OTP codes should only be sent after the password is verified. 3. U2F requires the site to share which devices are registered which can only be done after the password is verified. You may be able to make it work UX-wise if you separat…

Your login form doesn't need to display an empty second factor input. Your server can send back a specific error code on first login attempt that can be used by the UI to prompt for the user's second factor, whatever that may be (or even give a choice, in the case of multiple second factor types). For example, given this /login request to our server: POST /login Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego= Depen…

Good point.

It does leak a little information. It leaks the type of 2FA the user has configured and a list of devices for U2F (since that needs to be provided to authenticate). But that is likely acceptable.

Re: Tell HN: Somebody implemented something I wrote a blog about

#120

Post by jabbany »

ezekg wrote: post #25

Related: I think it's surprising how many services leak whether or not a password is correct. E.g. bad password => error, good password => 2FA prompt. You should verify a user's second factor before password.

This is not a huge deal in practice and can be a good honeypot/alarm system.

Most services today have fairly low "lockout" + "notify" thresholds on wrong passwords so brute force spraying passwords is already out of the question.

Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them. If, however, the password is correct, then the attacker gets hit with the 2FA surprise. Assuming the great suggestion in this post is implemented (it really should be), the attacker now is stuck--abandoning the login or trying an incorrect 2FA could all trigger notifications to the user that their password was breached [re: the "Was this login you?" prompts implemented by major services after these situations]. Attackers would need to also solve the 2FA in some reasonable period to "disarm" such an alarm.

Real users who happen to fumble once or twice are also fine, since they won't be surprised about the login confirmation as it really was them.

Post reply on HN