We do have all edge cases brought to us solved in terms of account linking and the recent changes further improve the user experience in these scenarios. There are many credential types around these days from passkeys to OTP codes to passwords and OIDC. The biggest challenge is always ensuring the flows are secure which is the hardest part in our view.
ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away. It would be much better if FusionAuth focused on releasing open source themselves and truly contributed back to the security community instead.
That's great you covered all the use cases you've seen. I'm sure you'll continue to build out this useful functionality. Agree that making sure the flows are secure is critical.
> ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away.
Hmmm. Appreciate the feedback. I try to avoid shilling, be upfront about my employment, and add useful comments to any auth related posts on HN, not just those about Ory.
I have a lot of respect for what Ory has built (for example, I featured your post about multi-region CIAM in my CIAM newsletter: https://ciamweekly.substack.com/p/multi-region-ciam ), but I will bring my own perspective to my comments, and that is definitely colored by my experience at FusionAuth as well as the fact they employ me.
Glad I am not the only one who noticed, and not just Ory posts. Once in a while, the leading question and last paragraph of how “my product X solves this” is okay. Sometimes even informative. But too often and bleh it is like spam.
The flow is essentially what you see in the small video on the docs page and can be set up in the Ory Network Console with a few clicks. I agree though that the docs here are a bit thin.
Pricing wise this is available on the Scale tier currently dubbed as "Enterprise SSO" although "B2B Organizations" probably would be more correct: https://www.ory.sh/pricing/
There are no limits to how many organizations you can have.
Regarding MFA - the MFA enforcement typically is the responsibility of the IDP the company owns. So for example dean@companyA.com use Okta and they enforce 2FA for their users. anna@companyB.com use OneLogin and they do not enforce MFA.
In terms of other enforcement, I meant more wrt to an organisation that _didn't_ use another IDP but still wanted to apply PW policies (for example) on their domain.
Could you create an Ory project (sorry, don't know all your terminology) to forward on to?
Something like:
Our app -> Ory -> split by domain -> Ory for specific domain -> Policies.
We have worked quite a lot on making Ory Kratos easier to consume. In the release notes you find ~4 CLI commands you can use to get a fully working Ory Kratos up and running, with all UIs and configuration management :) You should give it another try!
Yes, this is definitely true. However, there are use cases and companies who rely on SMS based two-factor:
- Using SMS for phone verification
- Using SMS for mobile login (think dating apps for example)
- Using SMS for two-factor where other factors are not available / convenient (often in emerging markets)
SIM Swap Attack, SIM Port Hacking are all real, but as always in security it comes down to your threat model to decide what's acceptable risk and what isn't.
Plus you have to consider the amount of support you inherit when using something less universal (and generally fool-proof) than SMS.
"The one-time code won't work!"
"The authenticator app doesn't work!"
"The email takes forever to arrive!"
"I never got the email!"
Most of that sort of thing goes away with SMS. It's not that SMS never fails, but every mobile device takes it, it's relatively simple, and very reliable. An alternative approach may be more secure, but require more hand holding, and not every organization wants to do that.
In a similar vein, it's not necessarily prudent to do everything that infosec experts espouse. For an analogy, businesses should consult lawyers, but if they follow every bit of advice from a zealous lawyer, they might never take necessary risks that allow the business to achieve excellence; as well, they may need to dedicate substantially more time and effort on compliance.
> - Using SMS for mobile login (think dating apps for example)
Dating apps in particular seem to be a problematic example to me. In some regions, phone numbers change owners quite easily (e.g., no possibility to port a phone number to a new contract, and quick re-cycling of the phone number when a contract is terminated).
To be fair, it really depends on the region you're operating. Some regions (like most places in Asia) use this as the primary identifier (instead of email), so despite the very obvious security flaws you might be simply be forced to offer it.
Right, by this point the global norm is to rarely, if ever, use email (or a computer larger than a smartphone) unless you work in an office (and in some places not even then). The phone number is the primary identifier for mass-market apps in most countries.
It's not just emerging markets. Many people are not capable of setting up authenticator apps, not everyone is a "techy" and not everyone is smart. Those people use the internet too.
SMS token is something that is much easier to use. 2FA with SMS is still a lot of added security in comparison to no second factor at all. Especially for people who use insecure passwords.
> Many people are not capable of setting up authenticator apps, not everyone is a "techy" and not everyone is smart.
That might be true but on the other hand most companies using Teams etc. will be introducing 2FA with the MS Authenticator App. Techie or not, you need to install an app and scan a QR code.
Once again, not every person using the internet is working for a company.
If you don't know anyone that will just laugh at you when you tell them "it's super easy, you just need to install an app and scan a QR code", then you're living inside a bubble. Every year at my mums birthday party her friends already queue up in front of me, so I can install some apps for them.
Are they too stupid (I don't mean that in a condescending way) or just too lazy? I know several elder people (75 to 85 years old) that have no problem installing apps on iPhones. On the other hand I know others that "play dumb" but I think it's mostly an issue of fear.
I agree with you, SMS as implemented almost everywhere* is bad, adding an account takeover path (the reset by SMS) with insufficient value-add to offset that 100% guaranteed (see research I linked elsewhere in thread) path to account takeover.
And as to "You're not seriously saying that adding a second factor is reducing security?" -- yes I am, when it's not a second factor, it's implemented as an "only factor".
* Note: And by "as implemented almost everywhere", I mean so indistinguishable from everywhere that that effectively boils down to "SMS is bad", much easier for users and builders to understand, when better options are available.
It mostly doesn't make sense, unless used exclusively as second factor, never only factor.
- phone verification: OK, but this wasn't about that, and having to have phone numbers in a database means you're maintaining PII, which is a liability, see regulator-related story below.
- mobile login (think dating apps): should be passkey, sign in with Google/Apple, or oauth of users' choice, see Twitter story below
- two factor where other factors are not available: in the case of SMS this actually means for two ways to get into the account, not two factor, see IsSMS2faSecure slides below.
SMS is an anti-pattern, generally less secure than a good password (something you don't even need to know w/ passkey) and biometrics (something you have/are) as it opens your threat model up to anyone with social engineering skills to take over your account (something anyone can do).
This was demonstrated dramatically a few years back by a research team calling the phone companies and being 100% successful on major carriers.
The slides here are eye opening if you're thinking SMS is a good idea:
We have the $400M FTX sim swap and this year the SEC's sim swap to remind us nobody is immune when SMS is at play, and people can't claim to not know about it since it's now widely covered:
The FTX case highlights a growing awareness among prosecutors and regulators of the ease and prevalence of SIM swap schemes. Reading the Powell indictment is not unlike reading one of the hundreds of credit card theft indictments that federal and state prosecutors pursue each year. As far as frauds go, SIM swapping is low-cost, unsophisticated, and rote. But, if you’re a criminal, it works.
SIM swapping works largely as the result of vulnerabilities in the telecom’s anti-fraud and identification protocols, and as the result of relatively weak anti-fraud and identification verification procedures used as the default for all too many online service providers, including financial services firms.
Bottom line, and putting this "global user" story to bed, if Twitter can dump SMS across emerging markets (not a lot of blue checkmark subscribers), so can everyone:
All that said, @andix is correct in that if you're going to use it, you must not allow password resets or account takeovers with SMS. SMS must be strictly second factor, never "only factor": https://news.ycombinator.com/item?id=39467039
SMS 2FA is only ostensibly about security. Mobile providers always sucked at it and never advertising that they were selling high quality identification services in the first place. They've actually gotten better at it but it wasn't ever there thing and still isn't.
Phone numbers are excellent PII for user tracking though AND allow companies to dump a lot of the hard support work on some one else. Gobbling up PII to sell and externalizing the hard support stuff to some one else is how tech companies and increasingly any company works these days. So it isn't a surprise it isn't going anywhere. You'll likely need to cough up a number at least for "verification" anyway (since they want it) so they'll probably just use that for account recovery to while they're at it to make their lives easier.
We build stuff for an emerging cloud infrastructure. It’s security, zero trust, hardcore bullet proof engineering. It’s Golang, K8S, React, Hashicorp etc. - no more buzzwords! Just drop us a short introductory email to jobs@ory.sh. We believe that great engineering deserves to be paid accordingly.
Our open positions (all full-time in Munich, Germany):
Couldn't agree more with these points. I'd like to point out that
> It isn't a bad idea to read and learn from the OAuth 2 spec in order to make your own auth services
has actually lead to quite horrible auth systems. I've seen bad stuff in large enterprises due to this ("we're smarter, we'll solve it for our use case" -> "Oops, we didn't think about session replay").
I recommend OAuth2 for complex systems with many involved parties and clients. There it can really reduce complexity. For normal apps with maybe 1-2 consumers, cookie-based security is secure and good enough!
Hmm yes, good point. Have slightly adjusted the post.
Assuming you have fully read and understood the OAuth spec, I find that it can be a helpful resource to identify the more complex considerations that might be easily missed in a home-grown auth implementation.
That being said, in my company's case, I haven't entirely followed my own advice, and we did implement our own OAuth 2 server. But we do know the spec pretty comprehensively.
You say as if there's no way to get a bad food supply outside of captivity.
It's not a inherent part of captivity. If some prison started beheading people every thursday, it wouldn't be "prison" that kills people, it would be the beheadings.
Why are developers of popular database solutions so reluctant to write secure-by-design software. You would guess that some basic form of authentication should be implemented in any internet-facing service. But here we are, after the MongoDB fiasko, still left with thousands of vulnerable services because someone didn't bother to implement basic auth.
Because these tools follow the unix philosophy of building single use tools. There are a wide variety of authentication measures that can be composed with databases to secure them. There is really no need to build the authentication into the database itself and it fact doing so would violate a don't repeat yourself ethos.
ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away. It would be much better if FusionAuth focused on releasing open source themselves and truly contributed back to the security community instead.