Auth0 OSS alternative Ory Kratos now with passwordless and SMS support(github.com)
github.com
Auth0 OSS alternative Ory Kratos now with passwordless and SMS support
https://github.com/ory/kratos/releases/tag/v1.1.0
113 comments
If my SMS is compromised, it's one thousand times easier to shut it down and recover than if my email is compromised.
^ Right?
^ Right?
I discovered another reason to avoid SMS OTP: I am currently visiting India and I have put my phone in Airplane mode because my Canadian phone company , Rogers,charges $15 per day for roaming and it is simply cheaper to buy an Indian SIM card and use it on an old phone to act as a wifi hotspot for my actual phone. So while my phone is in Airplane mode, I am unable to use my RBC Visa or MasterCard for any online purchases in India as there is no way for me to get the SMS OTP without paying Rogers the CA$15 .
That is very high. Australian providers offer free incoming SMS even when roaming internationally. The charge is only for data which you can disable. Vodafone Australia has $5/day roaming.
Surely you can just turn off data roaming…
SMS OTP sucks but this isn't it. Receiving text abroad is free with almost all carriers including Rogers.
[deleted]
Congratulations, this is a big release. Some great features in there. Love the phone number as a first class citizen, something we've been considering for a while.
(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 [email protected] but later wants to link [email protected]?
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.
(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 [email protected] but later wants to link [email protected]?
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.
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.
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.
> 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.
This is a massive release, well done! I run Kratos and Oathkeeper self hosted on ECS for our onboarding app (Xero only in Australia for now I'm afraid, xonboard.com.au). Works like a dream for the most part.
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?
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?
Our roadmap for this year has a revamped Ory Elements v2, which will make this a lot less painful!
> 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.
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 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.
> SMS support
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.
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.
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.
Hope this makes sense (maintainer here).
- 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).
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.
"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.
Meanwhile, the AT&T mobile network is down in the US, heh.
I do agree with your statements.
I do agree with your statements.
Gotta admit, it's a funny coincidence. Stupendous timing, AT&T.
> - 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).
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.
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.
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.
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.
It doesn't "add" security, it "adds" an account takeover path.
How is a second factor adding an "account takeover path"? You're not seriously saying that adding a second factor is reducing security?
We can agree that password reset via SMS token is bad. It basically reduces everything to one factor login via SMS.
We can agree that password reset via SMS token is bad. It basically reduces everything to one factor login via SMS.
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".
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.
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.
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:
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 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
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.
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.
It depends. Using SMS as a second (!) factor is fine. There are better options, but SMS is much better than no second factor at all.
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.
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.
This. I wish this distinction was recognized more.
Sadly people are like sheep. They hear SMS and shout unsafe.
> I thought it was well-established that SMS text messages should not be used for authentication purposes?
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.
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.
Right. But for validation they can still be useful if you need a way to prevent (or at least hinder) users to create lots of accounts.
SMS has problems, it's true. But every MFA method for consumers has issues, and for some applications it is a viable solution.
I wrote more about that here: https://ciamweekly.substack.com/p/ciam-mfa
I wrote more about that here: https://ciamweekly.substack.com/p/ciam-mfa
I think it’s biggest problem is when used for account recovery and password reset, not login 2nd factor.
Yes, but if you want large enterprise customers such as regulated financial institutions where lots of money's at stake, you will need to support SMS as a second factor, mothers' maiden names, and bypassing all that when the user has forgotten.
Interesting, in the European Union SMS token are mostly illegal for financial services, because they are not considered safe enough.
It would be lovely to have that in the U.S., but I doubt it will go anywhere anytime soon.
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'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.
Still funny to hear that everyone in the US has a social security number, although there is no public healthcare for everybody. And I always thought it's the land of unlimited freedom, doesn't seem to apply to privacy.
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 ;)
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 ;)
That's either recent or wrong, I'm in the UK and certainly they're not new since 2019 or whenever we left (I was going to say 16 but I realised that was the vote not actual exit, but longer than that anyway).
I think the last extended deadline of PSD2 was end of 2020, so after Brexit.
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 ;)
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 ;)
We have PSD2 though; I think we're voluntarily (or perhaps conditional in the exit negotiation) signed up to it anyway, perhaps so that 'open banking' works internationally still?
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.
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 can cleary assert that is not the case in all the European countries where I have bank accounts.
Yes, exactly. SMS should be an option because it is obsolete, and therefore unsecure.
Everyone says this here, but no one has shown any concrete proof that SMS could be hacked more easily than say TOTP.
You can use social engineering (or corrupted workers) to issue SIM card for other people and receive SMS. This method is widely used to steal money from bank accounts in my country. Telegram accounts also known to be stolen this way.
Of course you should be located in the same country. But it's a risk nonetheless.
Of course you should be located in the same country. But it's a risk nonetheless.
SMS is better than nothing, but I personally know several people who had their accounts compromised because their SMS 2FA codes were intercepted. It's not possible to do this with TOTP.
How were they intercepted? Was it a sim takeover, where the attacker took over the phone number? Or intercepting the code over the air, since SMS has no encryption?
The latter.
How can I someone see other's messages? Surely someone has step by step guide if it is that easy. Are you sure it was interception without SIM takeover?
It's not that you can do this just from any old device by flipping a built-in switch, but it's not that different from observing plaintext traffic over an Ethernet network with the right software.
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
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
Again, I want the tool through which I can see other people's messages, or at least a video of some hacker doing that. e.g. I can observe plaintext message over ethernet by using some splitter and wireshark.
So they had weak passwords? Or were their accounts recovered/reset via SMS which is prevalent but not 2nd factor login.
there are tons of articles here in HN that have shown that SIM swamp (at least in US) is much easier then trying to brute force (or using quantum computer) to break TOTP encryption. One of main reason for SMS is also meta data collection of your number.
Give some examples then. I can't find any article.
You haven’t looked for any proof: search for sim cloning.
In the first link:
> In SIM cloning attack, the fraudster gains access to the victims physical SIM card and..
Same thing could be done with TOTP.
> In SIM cloning attack, the fraudster gains access to the victims physical SIM card and..
Same thing could be done with TOTP.
It’s not the same. The explanation you quote is wrong.
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.
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.
> no one has shown any concrete proof that SMS could be hacked more easily
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:
https://www.issms2fasecure.com
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:
https://www.issms2fasecure.com
Seems like a good place to ask: Does anyone have advice on good solutions for B2B SAAS apps?
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 [email protected] 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.
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 [email protected] 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.
Have a look at ZITADEL (https://github.com/zitadel/zitadel or https://zitadel.com/), I think that does what you want.
You can create multiple tenants (called Organizations) and you can setup security / login rules per organization such as enforcing MFA. Furthermore you can configure on each tenant a separate SSO and users are directly forwarded to their identity provider.
When you first enter your username (could be an email) on the login screen, the policies of the user's organization will be applied. That allows you to route users based on their email domain etc.
One additional thing to mention is that ZITADEL does not only handle authentication, but also authorization with self-service. Managers of an organization can, for example, assign users of their organization roles.
That sounds like just what I want.
ZITADEL was already on my list to try in the next round.
Can you clarify the pricing / plan required for that feature set?
ZITADEL was already on my list to try in the next round.
Can you clarify the pricing / plan required for that feature set?
All of these features are included. Main drivers for pricing in this case, I assume will be daily active users (sum over the month) and how many third-party identity providers you have configured. Unlimited tenants, users, permissions etc. are included.
We use DAU instead of MAU, since there are many different use cases and that seems work quite well. Just take the MAU and multiply by how many times per month your users will sign-in.
In the enterprise tier we offer more custom quotes for higher volumes, guarantee requirements, and support SLAs.
And to clarify on the third party providers. Assuming every org is using Azure - that’s 1 provider per org. So 53 orgs would be an extra $1,000 / month?
Yes that's correct. Get a quote for your use case, if you are already running on higher numbers. Pricing might not fit all cases, that's why there's also an Enterprise tier.
Hmm, maybe take a look at their website? https://zitadel.com/pricing
We built Stytch's B2B SaaS solution with this specific shortcoming in mind -- most other solutions aren't actually built with an organization-first data model (they're user-first like Auth0 but support the general concept of orgs), which makes it difficult to offer those per organization controls in an ergonomic manner.
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
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
That looks really close to what I’m after! Will give it a spin.
I’m also interested in this. We’ve been using Auth0 for a year and our contract is up for renewal where we will be getting kicked off of the startup plan. I’m wanting to rip the bandaid off early as we’re about to launch a new platform.
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?
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?
Have you tried WorkOS? It’s built for exactly this, with native support for SAML and SCIM.
https://workos.com/
I’m the founder. Would love to hear your feedback and happy to answer questions.
https://workos.com/
I’m the founder. Would love to hear your feedback and happy to answer questions.
No, I haven’t tried it. It looks great but unfortunately the per connection pricing makes it not ideal for us. (We’ve had a couple of messages back and forth on here in the past about it). Most of our customers have low numbers of users, so the per subscription cost becomes a bit high.
I’ll kick the tyres in my next round of investigation though to see how it looks.
I’ll kick the tyres in my next round of investigation though to see how it looks.
What's on your shortlist?
Auth0 can do this. Identifier first login, SSO domain aliases, and MFA are all supported. They have an Organizations feature as well, but I'm not certain if you'd need that from what you've described. Customization of various aspects of the authn flow can be done via Actions (and Rules, but they're deprecated).
Hey, for authentik this is actually something we're actively working on: https://github.com/goauthentik/authentik/pull/8330, and this will be included in our next feature release in April!
(Disclaimer, I am founder and CTO of authentik)
(Disclaimer, I am founder and CTO of authentik)
We have this feature and it is called B2B SSO: https://www.ory.sh/docs/kratos/organizations
Interesting. Any more details available on what’s configurable? How does it work out pricing wise?
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 [email protected] use Okta and they enforce 2FA for their users. [email protected] use OneLogin and they do not enforce MFA.
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 [email protected] use Okta and they enforce 2FA for their users. [email protected] use OneLogin and they do not enforce MFA.
Thanks.
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.
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 not OSS?
Most of the commercial solutions break financially when you have a freemium tier; orgs that don't pay below a certain size or usage. Yet the auth provider charges you the same fee for each such org.
Hmm. (I work for FusionAuth, thanks for giving us a try!)
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?
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?
For the moment our needs are actually fairly light. I'm trying to remember exactly what I ran into with FusionAuth but struggling a little unfortunately.
Gotcha. We definitely don't have fine granularity around when MFA is required (open issue here: https://github.com/FusionAuth/fusionauth-issues/issues/2285 ).
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!
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!
Thanks. I appreciate the info. Will give it a shot when I revisit this in a month or so.
It’s not really an alternative to Auth0. It’s certainly a component of an alternative to Auth0.
This isn’t very substantive, can you go into more detail about what’s missing?
Ory Kratos is an identity management solution with MFA, passwordless, WebAuthn and so on, so I would argue for most use cases it alone is comparable.
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.
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.
Note that this software unethically phones home with your usage data without your consent. Such opt-out, on-by-default spyware exfiltrates your data silently. They claim it’s anonymous, but that’s false as it includes your client IP address, which frequently maps directly to physical location.
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 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.)
If you look in the source code for this software which is provided for everyone to see you will realize that Kevin Goslar is entirely innocent of this heinous crime.
He merely added the copyright headers to each file.
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.
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.
This practice being considered acceptable has been a nightmare - we had OSS libraries add spying later, change their APIs for disabling it, etc. When it's a nested dependency, even worse.
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.
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.
Developers are not entitled to knowledge of what software runs or does not run on machines that do not belong to them.
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.
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.
If this is indeed "spyware" (which it isn't) they sure do a poor job of hiding it from you.
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.
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 has SMS support long ago: https://casdoor.org/docs/category/sms
Casdoor is much more way powerful than Kratos: https://casdoor.org/
Casdoor is much more way powerful than Kratos: https://casdoor.org/
Ory Kratos is using 7 docker containers to run, seems super heavy compare to Keycloak that will run with just 2 containers. What is justifying the bloat?
I looked at using the Ory stack when they were much younger, and had some chats with their team. Ory builds everything with the expectation that you're a large enterprise, where service classes and systems are expected to be scaled. They're also pretty big k8s adopters, so they all but expect that you want to run your workloads in a large environment. Great for folks that are bringing Auth* home from Auth0/Okta, etc, as scaling for each app class is right there, but also a much more complex stack to begin with.
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.
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.
Magic links to email and sms, which are unencrypted, for signup and login, account linking and then converting the session cookies to valid jwt?
I smell a CVE within a year.
I smell a CVE within a year.
All password resets lead back to email.
Been using it in production for a bit less than 2y now. It has improved a lot, the configuration is still kinda hard (jsonnet is really ugly IMO) and there are a lot of weird decisions (like you can change the password without knowing the current password if you have login within the last X minutes even coming from a social provider) but overall it is a solid contender in the space now.
I always wanted to use Kratos for my own open-source projects, but I never got far enough into the researching how support for adding different storage options is.
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.
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.
Is this comparable to Authentik?
Ory Kratos is so complicated .Authentik is much simpler and easier.
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!
I will give a try. Back in 2023 it's very complicated to build own web application backend and frontend with it so we ended up choosing Authentik.
Unfortunately this is not comparable to authentik for me, it looks like it’s only for applications you’re developing and not already implemented solutions
What do you mean? I think it supports oidc endpoints? https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow indicates this.
passwordless via email is the single thing that I've been waiting for, once I integrate this I can disable Auth0 and still support the OSS SaaS forum platform — this previously required an Auth0 account, and has sent Auth0 at least 10 medium sized customers.
SMS? Really?
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