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

Substack's UI and 1Password temporarily cost me $2k

timmyomahony.com

Post reply on HN
Print view View original

201–210 of 278 posts

Re: Substack's UI and 1Password temporarily cost me $2k

#201

Post by kiririn »

tedyoung wrote: post #2

I wish sites would test their forms with popular password management systems. This kind of thing happens all too often (thought perhaps not with such a high cost). Why not make it easy for people who auto-fill with these programs -- don't fight them. (And I won't get into sites that won't let you paste passwords into their forms.)

I’d settle for login forms that don’t hide the password box until you enter your username/email.

I don’t see how they benefit real users in any way, and my password manager can’t understand it, requiring manual copy/paste entry

Re: Substack's UI and 1Password temporarily cost me $2k

#202

Post by wccrawford »

metafunctor wrote: post #199
yoz-y wrote: post #159

Earlier quoted context omitted.

I have little faith site developers care about password managers. Many even try to block them from working due to some perceived notion that they are insecure.

What, is "password managers are insecure" really a thing?

Yup. And they are, technically, because if someone has that one login and password, they can access all your accounts.

But it turns out that keeping that 1 login and password in your head and trusting the rest to your password service (especially if you let it make random passwords) is way more secure than what people do if they have to try to keep them all in their head.

So it's about relative security. Both sides are correct, in their narrow views of the situation.

Re: Substack's UI and 1Password temporarily cost me $2k

#203

Post by filleduchaos »

pnt12 wrote: post #192

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd. The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app. This is already possible in Portugal with an app where you c…

> users need to give free access to their credit card for payment, at the promise that the other party will play nice

This is something I only encounter with American companies/sites/processors. When I shop or pay online locally, 3-D Secure is always required.

It's kinda appalling how much of the web/online experience is negatively impacted by US norms.

Re: Substack's UI and 1Password temporarily cost me $2k

#204

Post by yoz-y »

metafunctor wrote: post #199
yoz-y wrote: post #159

Earlier quoted context omitted.

I have little faith site developers care about password managers. Many even try to block them from working due to some perceived notion that they are insecure.

What, is "password managers are insecure" really a thing?

Yes, if not explicitly then by their actions definitely. E.g.: there is only a single bank in France that hasn't switched to a stupid 6-8 digit system where you have to click buttons that appear in random order. Before then they often disabled autofill on passwords (luckily that could have been easily bypassed). They incessantly re-invent the wheel for 2-factor auth and so on. I find it very curious why banks of all institutions are those with the worst security.

Re: Substack's UI and 1Password temporarily cost me $2k

#205

Post by filleduchaos »

Nextgrid wrote: post #198
pnt12 wrote: post #192

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd. The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app. This is already possible in Portugal with an app where you c…

Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid. We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).

3-D Secure was introduced in 2001.

Additionally, I don't quite think making a payment is within the problem domain of OAuth. Most often I'm explicitly not trying to give the site access to my account - I'm trying to fulfil one request.

Re: Substack's UI and 1Password temporarily cost me $2k

#206

Post by yoz-y »

wccrawford wrote: post #202
metafunctor wrote: post #199

Earlier quoted context omitted.

What, is "password managers are insecure" really a thing?

Yup. And they are, technically, because if someone has that one login and password, they can access all your accounts. But it turns out that keeping that 1 login and password in your head and trusting the rest to your password service (especially if you let it make random passwords) is way more secure than what people do if they have to try to keep them all in their head. So it's about relative security. Both sides a…

I believe security should optimise for the threat levels on the order of importance. No.1 is password reuse, which is what password managers solve.

Re: Substack's UI and 1Password temporarily cost me $2k

#207

Post by pnt12 »

Nextgrid wrote: post #198
pnt12 wrote: post #192

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd. The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app. This is already possible in Portugal with an app where you c…

Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid. We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).

I don't like integrations such as oauth on mobile apps, where the URL is often hidden.

Validating in some other application) website seems reasonable to me.

Re: Substack's UI and 1Password temporarily cost me $2k

#208

Post by benhurmarcel »

yoz-y wrote: post #204
metafunctor wrote: post #199

Earlier quoted context omitted.

What, is "password managers are insecure" really a thing?

Yes, if not explicitly then by their actions definitely. E.g.: there is only a single bank in France that hasn't switched to a stupid 6-8 digit system where you have to click buttons that appear in random order. Before then they often disabled autofill on passwords (luckily that could have been easily bypassed). They incessantly re-invent the wheel for 2-factor auth and so on. I find it very curious why banks of all…

Not sure if that's the bank you're talking about, but FYI Fortuneo lets you use a normal password.

Re: Substack's UI and 1Password temporarily cost me $2k

#209

Post by gberger »

nodesocket wrote: post #75
monkin wrote: post #14

Earlier quoted context omitted.

It’s not 1Password fault, but poor design and implementation. :-)

Substack. A payment form should NOT allow you to enter any price in text fields, hidden or not.

Why not? It's an arbitrary donation amount.

Re: Substack's UI and 1Password temporarily cost me $2k

#210

Post by Nextgrid »

pnt12 wrote: post #207
Nextgrid wrote: post #198

Earlier quoted context omitted.

Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid. We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).

I don't like integrations such as oauth on mobile apps, where the URL is often hidden. Validating in some other application) website seems reasonable to me.

That is an implementation detail - OAuth itself works on the basis of web URLs so it's absolutely possible to open the login URLs in the default browser instead of in a web view.
Post reply on HN