3 ms·

The android app sign up page seems to want me to enter my Google username and password _inside the app,_ in what looks like a web form, but as a user I have no

The android app sign up page seems to want me to enter my Google username and password _inside the app,_ in what looks like a web form, but as a user I have no way to tell if the app is snooping on my password. It seems like Apps usually navigate away to a sign in, and then navigate back. Is that pattern hard to implement? Is the issue about cross platform support? Thanks

carstenhag 3y ago
It's not super hard in principle. I work with car manufacturers, we have to let the user login via their OEM account. In theory they say it's all compliant, but then many parts don't work and take ages for them to get fixed. What you described should really not happen though, I thought Google forbid this already
inquirerGeneral 3y ago
[dead]
avandekleut 3y ago
This is called OAuth 2.0 and is trivial to implement with something like Okta.
- explaininjs 3y ago
  Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta https://hn.algolia.com/?q=okta
  - jwineinger 3y ago
    This feels a bit like NIH syndrome to me. Maintaining your own authentication solution is not trivial, especially for small/one-person operation. Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.
    - JonChesterfield 3y ago
      Yeah it is known that one should use a library for authentication. It's also observed that they keep getting breached. The two sentiments "Best practice is use Okta" and "Okta keeps falling over" are inconsistent but the industry doesn't seem to have worked out what to do about this yet.
      - explaininjs 3y ago
        > Yeah it is known that one should use a library for authentication. A library, yes, but a library is not a service. If you self host your auth stack with trusted primitives from a well known crypto library, you're much better off than if you outsource the very security of your platform to a company that has time and time again shown that they are incapable of preserving the security of even their own employee's personal info, much less anyone else's. At this point it would be arguably criminally negligent to rely on them to protect any sort of private information for your customers. If you self host, someone needs to personally pick you as a target and find a flaw you made to get into your system. With Okta, they in all likelihood already have access. I know this industry loves learned helplessness (especially when the solution is “you don’t have to know the fundamentals, just pay us every month and we’ll do them for you!”), but come on.
  - spencerchubb 3y ago
    Is there really a better alternative? Using a centralized service is certainly more secure than every company implementing a bespoke auth system. Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
    - aragilar 3y ago
      There are enough solid systems (such as keycloak) that implement standard mechanisms (such as OAuth2 or OIDC) that using a service that continually has issues (as noted by the gp) should be justified, not assumed (having an SSO system should not be conflated with a specific provider).
    - shortrounddev2 3y ago
      I always thought it would be cool to have everybody carry around a private key on some device, and that key signs all data to prove authenticity. Instead of creating user accounts on a forum, posts would be signed with a key and a hash would be appended to the username, so you know that this John Smith is the same one as the last post because he has the same hash appended. Kind of like what 4chan does with tripcodes
      - mschuster91 3y ago
        You'd instantly have to deal with people losing their keys, people damaging their keys, people's pets eating, digesting and defecating the keys, fire/floodwater/storms/earthquakes/other natural or man-made disasters destroying the keys, keys getting damaged by ESD or cosmic radiation, people stealing other people's keys for extortion or abuse... spread any technology over millions of people and you will experience all sorts of failure modes that you haven't even thought of. All of these failure modes need some sort of "customer support" to work out, otherwise they'll not be used by users at all or they'll lead to shitstorms when people are locked out of their identity. And if the customer support makes errors or gets bribed, you'll get shitstormed too. And allowing people to back-up their keys isn't an option either because that defeats the purpose of why you have an HSM anyway. Security is hard, PKI is even harder.
  - intelVISA 3y ago
    Rolling your own is rolling the dice, but using something like Okta is guranteed (to leak).
- ianschmitz 3y ago
  Why would you need Okta for a simple Google sign in? A simple traditional Google OAuth flow should work just fine.
nathandaly 3y ago
I should have started out by saying this looks really neat, which is why I downloaded it to try out on my phone! :) thanks for sharing! Sorry my only comment was a criticism/question. Looking forward to trying it out on the computer instead!

carstenhag 3y ago

It's not super hard in principle. I work with car manufacturers, we have to let the user login via their OEM account. In theory they say it's all compliant, but then many parts don't work and take ages for them to get fixed. What you described should really not happen though, I thought Google forbid this already

inquirerGeneral 3y ago

[dead]

avandekleut 3y ago

This is called OAuth 2.0 and is trivial to implement with something like Okta.

explaininjs 3y ago
Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta https://hn.algolia.com/?q=okta
- jwineinger 3y ago
  This feels a bit like NIH syndrome to me. Maintaining your own authentication solution is not trivial, especially for small/one-person operation. Edit: Re-reading, I guess this is specifically targeted at Okta, who have had their share of problems.
  - JonChesterfield 3y ago
    Yeah it is known that one should use a library for authentication. It's also observed that they keep getting breached. The two sentiments "Best practice is use Okta" and "Okta keeps falling over" are inconsistent but the industry doesn't seem to have worked out what to do about this yet.
    - explaininjs 3y ago
      > Yeah it is known that one should use a library for authentication. A library, yes, but a library is not a service. If you self host your auth stack with trusted primitives from a well known crypto library, you're much better off than if you outsource the very security of your platform to a company that has time and time again shown that they are incapable of preserving the security of even their own employee's personal info, much less anyone else's. At this point it would be arguably criminally negligent to rely on them to protect any sort of private information for your customers. If you self host, someone needs to personally pick you as a target and find a flaw you made to get into your system. With Okta, they in all likelihood already have access. I know this industry loves learned helplessness (especially when the solution is “you don’t have to know the fundamentals, just pay us every month and we’ll do them for you!”), but come on.
- spencerchubb 3y ago
  Is there really a better alternative? Using a centralized service is certainly more secure than every company implementing a bespoke auth system. Also, there are super strong incentives to hack Okta, so naturally more people will try to hack Okta.
  - aragilar 3y ago
    There are enough solid systems (such as keycloak) that implement standard mechanisms (such as OAuth2 or OIDC) that using a service that continually has issues (as noted by the gp) should be justified, not assumed (having an SSO system should not be conflated with a specific provider).
  - shortrounddev2 3y ago
    I always thought it would be cool to have everybody carry around a private key on some device, and that key signs all data to prove authenticity. Instead of creating user accounts on a forum, posts would be signed with a key and a hash would be appended to the username, so you know that this John Smith is the same one as the last post because he has the same hash appended. Kind of like what 4chan does with tripcodes
    - mschuster91 3y ago
      You'd instantly have to deal with people losing their keys, people damaging their keys, people's pets eating, digesting and defecating the keys, fire/floodwater/storms/earthquakes/other natural or man-made disasters destroying the keys, keys getting damaged by ESD or cosmic radiation, people stealing other people's keys for extortion or abuse... spread any technology over millions of people and you will experience all sorts of failure modes that you haven't even thought of. All of these failure modes need some sort of "customer support" to work out, otherwise they'll not be used by users at all or they'll lead to shitstorms when people are locked out of their identity. And if the customer support makes errors or gets bribed, you'll get shitstormed too. And allowing people to back-up their keys isn't an option either because that defeats the purpose of why you have an HSM anyway. Security is hard, PKI is even harder.
- intelVISA 3y ago
  Rolling your own is rolling the dice, but using something like Okta is guranteed (to leak).
ianschmitz 3y ago
Why would you need Okta for a simple Google sign in? A simple traditional Google OAuth flow should work just fine.

nathandaly 3y ago

I should have started out by saying this looks really neat, which is why I downloaded it to try out on my phone! :) thanks for sharing! Sorry my only comment was a criticism/question. Looking forward to trying it out on the computer instead!