Auth0 OSS alternative Ory Kratos now with passwordless and SMS support
github.com
github.com
SMS is an anti feature at this point. This just moves the problem. Arguably email is actually better than SMS and that's not saying much. It's the difference between getting stabbed and shot.
What's the most common thing that people have stolen: wallets and phones. Lots of people have cheap phones, pre-paid sims, or worse. Tying your identity to some phone number that should be treated as temporary only to get locked out of your account some years later is just not great.
Here's a list of reasons people change phone numbers:
- they have a prepaid number and they switch to a different provider
- they travel and use a different sim while traveling
- they change job and lose access to their employer provided phone
- they change operator and the operator declines to take over the old number (happened to me in Germany)
- their phone number ends up on some list of scammers and to get out of the non stop spam by simply getting another number
^ Right?
(I work for a competitor, FusionAuth.)
I noticed account linking, between social accounts and existing accounts, based on email matching, was a new feature.
It's documented here: https://www.ory.sh/docs/kratos/social-signin/link-multiple-p... I believe.
The document walks through the "linking an existing account with a password to social account" scenario. I was wondering if there was also the ability to go the other way, from an existing social account to adding a password?
How do you handle the case where Alice signs up with a username of alice@example.com but later wants to link alice@gmail.com?
I also wonder if you can block account linking on a per user basis or if it is enabled for everyone in a system.
We've had account linking for a few years (documentation here: https://fusionauth.io/docs/lifecycle/authenticate-users/iden... ) and have had customers bring up some edge cases like this.
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.
> 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.
One thing which was very painful was adapting the custom UI. I started with an existing example project and adapted it but it was a confusing mix of server code and CSS in JS which made it very difficult to "get at" some of the HTML / CSS.
Any movement on that front with the project?
I cannot wrap my mind around why the vendors don't separate the UI and backend application; and then in the UI project, author it in something ubiquitous like React.
I thought it was well-established that SMS text messages should not be used for authentication purposes?
Here's the original feature-request: https://github.com/ory/kratos/issues/1570 - user @zepatrik raised concerns about this and everyone else just ignored him. Yikes.
Of course you should be located in the same country. But it's a risk nonetheless.
> In SIM cloning attack, the fraudster gains access to the victims physical SIM card and..
Same thing could be done with TOTP.
This is the correct one:
> SIM cloning is the procedure through which a genuine SIM card is reproduced. When the cloning is accomplished, the cloned SIM card’s classifying information is transported onto a separate, secondary SIM card. The secondary card can then be used in a different phone while consuming all the calls and related charges credited to the original SIM card.
https://fraud.net/d/sim-cloning/
There is no need to have physical access.
There are various ways to nab an SMS. Some are similar to SIM swap attacks in that they rely on social engineering or human or process fallibility to execute [1] [2], and others can grab messages right right out of the air, so to speak [3] [4]. This is in part because one of the foundational protocols that underlie modern cellular networks was never designed with modern security in mind. It's called SS7, and it's been extensively documented as a concern to the security of cellular based communications [5] [6] [7] [8].
Lot's of references because this is an area that has long fascinated me, and I have many bookmarks. There are also some recent papers on this behind paywalls (e.g., [9]).
In between the lines and lightly touched on in some reporting is a nuanced point that I think plays a larger part - one issue is that overhauling these older foundational technologies isn't just a matter of commercial and standards changes but also moving the goal posts on where lawful interception happens in the stack, how it happens, and the technologies that support that. For example in the U.S., law enforcement agencies can acquire devices that impersonate cellular infrastructure in order to force communications to go through law enforcement controlled equipment (called IMSI catchers). If we were to revamp cellular networks with a view toward security in the way we probably should, it's reasonable that devices like that wouldn't be feasible without being operated by the telephone companies that own the networks, and that would probably become some amount of red tape that law enforcement doesn't like.
[1] https://arstechnica.com/information-technology/2021/03/16-at...
[2] https://krebsonsecurity.com/2021/03/can-we-stop-pretending-s...
[3] https://www.firstpoint-mg.com/blog/ss7-attack-guide/
[4] https://www.youtube.com/watch?v=RXBvO8TWGsw
[5] https://www.theguardian.com/technology/2016/apr/19/ss7-hack-...
[6] https://arstechnica.com/information-technology/2018/05/nefar...
[7] https://arstechnica.com/features/2019/04/fully-compromised-c...
[8] https://www.zdnet.com/article/5g-networks-could-be-vulnerabl...
[9] https://link.springer.com/article/10.1007/s11235-023-01018-0
edit: formatting
On the contrary, here is an empirical study demonstrating 100% of the 5 major carriers in US used insecure authentication challenges that can easily be subverted by attackers:
- 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.
Hope this makes sense (maintainer here).
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).
"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.
I do agree with your statements.
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.
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.
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.
We can agree that password reset via SMS token is bad. It basically reduces everything to one factor login via SMS.
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".
To that point, btw, I'd linked to your other reply about resets from a couple of mine: https://news.ycombinator.com/item?id=39467039
* 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.
- 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:
https://www.issms2fasecure.com
https://www.usenix.org/system/files/soups2020-paper16-slides...
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.
https://www.coindesk.com/consensus-magazine/2024/02/12/the-f...
https://finance.yahoo.com/news/sec-blames-sim-swap-attack-fo...
https://www.theguardian.com/money/2024/feb/19/sim-swap-how-y...
It keeps getting worse:
"US insurance firms sound alarm after 66,000 individuals impacted by SIM swap attack"
https://www.bitdefender.com/blog/hotforsecurity/us-insurance...
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:
https://techcrunch.com/2024/01/23/x-adds-support-for-passkey...
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
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.
I'm sympathetic to the reasons. The U.S. has a massive population of people who for various reasons will not or cannot adopt methods other than SMS, if that.
Meanwhile you can call up some of our largest financial institutions and impersonate someone with public-record knowledge. Many organizations will allow you to skip any kind of over-the-phone SMS challenge by asking for -more- publicly available knowledge to "better"/further authenticate the caller. And of course all our Social Security Numbers are effectively all out there, and those are still the de-factor identifier where a phone number is not.
I used to do business with Vanguard. Several years ago they rolled out U2F-then-WebAuthn support so you could use a Yubikey or other FIDO2 compliant token as your MFA method. They allowed you to disable SMS MFA if you did that. I happily enabled that. Within two years, they re-introduced a requirement to enroll a number for SMS MFA on the grounds that their mobile app only supported codes delivered by SMS, and there was no opt-out. If you didn't enroll a number you'd be locked out and have to call customer service to add a number and reset your password.
I have a social security number too, but I need it to get free (actually less expensive) healthcare. Not for opening a bank account. I think in my country nobody except health care is allowed to process social security numbers, because it's considered private information. They are not allowed to store them. If they get them by accident they need to delete them ;)
And it's not unheard of, that some countries just ignore EU regulations. Especially if they are going to exit the EU before they can be fined ;)
Just from a cursory 'psd2 sms multifactor' search, I can't see anything definitively saying it's not allowed though? I can see 'must use secure MFA' (implying it might be pretty open to interpretation) and blogspam type sites saying 'the short answer is yes [SMS can be used]' or 'can be as simple as implementing SMS and voice'.
This one seems reasonable - https://www.onespan.com/blog/psd2-end-sms-based-authenticati... - and though his opinion is that it's not up to scratch, it does make it seem like it comes down to interpretation and your willingness to defend your position. Unless you know that it literally says 'must not use SMS' now?
Two examples I can think of are Santander, and NS&I (run by UK gov). The latter might not be a 'payment service' though I suppose (savings accounts only). I think NewDay (rebadged credit card aaS provider) too.
I wrote more about that here: https://ciamweekly.substack.com/p/ciam-mfa
Using SMS text messages for 2FA is barely better than 1FA, but it is better.
There's a lot of value in discouraging what many see as the easy option, especially when the alternatives are getting users to install extra apps (or even buy hardware keys of some sort), so the scaremongering around SMS is warranted, but it's still absolutely better than nothing.
What you absolutely shouldn't do is allowing password reset only via SMS token, because it's often not that hard to get access to SMS codes via social engineering (convincing a store clerk to issue a new SIM card, or stealing a phone and getting the code displayed on the lock screen)
Having SMS as second factor requires the attacker to know the password AND do some social engineering. It's a significant security improvement over password only.
SMS might even be safer than password less passkey login, if the user's passkey implementation is unsafe. It's possible to store passkeys in password managers, and people regularly manage to get their vaults compromised. This might only require a keylogger on a PC where the user logs in to the password manager.
Just our app that needs logging in to and would like to allow the usual things (password, social etc) but also allow customising the rules per email domain.
For example, if someone enters someone@example.com in to the login form they'll be shuffled off to this Azure connection for authentication. Or maybe they use our login pages, but MFA is enforced.
Things that I've tried (eg Authentik and FusionAuth) weren't well suited for per organisation controls.
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.
So you want a screen in front of the login process where someone enters their email address, and then a second screen where a variety of login options are presented?
Along with the ability to enforce MFA on a per domain basis?
Anything else you are looking to customize at the domain level, such as password rules or registration ability?
Other than that I'd suggest putting a page in front of our login pages with the domain logic, and modeling each set of emails as either an application, organization or tenant, depending on the specific features you need.
Either way, hope you find the right solution for your needs!
ZITADEL was already on my list to try in the next round.
Can you clarify the pricing / plan required for that feature set?
I’m the founder. Would love to hear your feedback and happy to answer questions.
I’ll kick the tyres in my next round of investigation though to see how it looks.
(Disclaimer, I am founder and CTO of authentik)
There's some more info on our multi-tenancy data model here (https://stytch.com/docs/b2b/guides/multi-tenancy), and here's the PUT request you'd use to manage any of those org configurations: https://stytch.com/docs/b2b/api/update-organization
I’m highly considering bringing auth in house with Keycloak. I’ve run it in the past at previous companies so am familiar with it, but it’s going to be an extra thing to maintain due to self hosting, their themeing also is not great. However this is pretty much an end all solution that doesn’t really get expensive over time as our user base grows.
Wondering if folks have any advice?
But there are two more Ory services; one for permissions / authZ and an OAuth2 server. You can make use of those to cover the full range of authN/authZ use cases.
You have to patch it out, because even if you try to turn it off, it still phones home in violation of your expressed wishes:
https://www.ory.sh/docs/ecosystem/sqa
> Disabling telemetry doesn't have any downsides, except for us not being able to improve the project. Note that Ory always sends minimal ping with version information once on start up.
Why do people feel entitled to spy on users of the software they gave away? I would never, ever even consider using their SaaS, or that of any other company these founders ever run.
https://github.com/ory/x/blame/master/metricsx/metrics.go
Kevin Goslar, formerly of Google (per his GitHub profile), is the one that committed this code (per the history publicly available on GitHub). It is somewhat unsurprising that free software at his new startup follows the same ethical framework regarding nonconsensual surveillance as the world’s largest advertising surveillance company where he used to work.
The trend of open source spyware is increasing. We need to be more vigilant both about the presence of spyware in open source software, as well as being mindful of the people who engage in such unethical practices. (For instance, Mattermost is another offender in this category.)
You misunderstand the purpose of the SQA telemetry.
There are some reasons for SQA telemetry listed in the doc you posted: - Be able to say how many production deployments exist. - Understand which features are used and how. - Understand how much throughput deployments handle. - Evaluate how frequently specific features are used. - Detect issues introduced by new features (such as a buggy releases). - Identify problems at scale (such as slow endpoints). - Understand which versions are deployed.
If you have concerns about privacy as you rightly noted you can turn it off with a simple flag (--sqa-opt-out) and if you don't like the version ping you can block in your network. Hundreds of users are running Ory Kratos without any telemetry sent without any extra work.
So if this is a plot to produce open source spyware it's not the best.
Now and then we run our stack with mitm monitor just to sniff out this dangerous crap. More recently, we are seeing it in ML libraries. For a security vendor to do it is extra bad because they can't claim not understanding why it's bad and often illegal.
To co-opt those machines without the consent of the user or device owner means your software is malware. To do so even after the user has explicitly opted out is even worse, and in my opinion, is criminal behavior.
With consent, it’s fine. Without consent, it is the same as any other spying.
Going so far as to tell you exactly what sort of harmless data they're collecting and even putting the code for doing so in a public repo, and then even letting you opt out of it.
Doesn't sound like any kind of spyware I've ever seen.
Casdoor is much more way powerful than Kratos: https://casdoor.org/
That said, where are you seeing 7 containers? I haven't grabbed the repo to run it, but their quickstart instructions use config overlays to manage specific configs, and none of the examples looked like more than 5 containers, 4+ your database, with 1 of them being a dev mail endpoint. Separating tasks out to 3 different services, frontend, backend, and DB migration, doesn't seem super big to me.
I smell a CVE within a year.
My project supports multiple storage back-ends (mostly around document storage) and I would like to get Kratos to query the same ones, even if it requires dev work on my side to add support.