Hey,

This is Gonto. I'm the VP, Marketing and Growth at Auth0. I want to assure you that in no way is Auth0's platform insecure, or is any customer domain at risk. This is not a vulnerability, a flaw, nor is there anything to be patched. To learn more about this, please check our blog post: https://auth0.com/blog/phishing-attacks-with-auth0-facts-fir...

Thanks!

> The specific idea behind the security researcher’s phishing scam was a way to target a website that uses Auth0 authentication. Auth0 supports regional subdomains: auth0.com, eu.auth0.com, and au.auth0.com. A bad actor could potentially attempt to scam users of a website or application that uses one of the subdomains by registering any of the other regional subdomains while using the same name. The attacker could then set up a custom page on their subdomain and, assuming that they had access to the email addresses of users, send them a link and attempt to solicit secure information from them. Similar scams could be attempted using any domain that users could mistake for a legitimate one.

I'm genuinely curious... why is registering an account on auth0.com doesn't automatically provision it on regional sub-systems eu/au.auth0.com? Is this a common pattern with other companies in general?

One random idea, not sure how practical - Do a screenshot analysis/pattern matching on all customer login pages. If verbiage or screenshot matches are close enough, it get's flagged for human review. This would only work on the pages at different auth0 domains obviously. Since the login url endpoints are saved in the Auth0 admin console, it could be easy to directly check the page. If that doesn't work, you could require customers store the login url's to make scanning them easier.

A potential easier approach could be detecting when an existing auth0 user attempts to access an abnormal auth0 subdomain. Even if the user gives up their user/pass accidentally you could send an email warning to review their activity. You can fingerprint the user's browser or ip address to help identify them if you don't have any other info.

This blog post doesn't actually respond to the main security concern raised.

"malicious-service-a.com" spoofing "service-a.com" is different than "eu.auth0.com" spoofing "au.auth0.com".

In the second case both domains are valid auth0 domains. This makes it harder for a user to detect the phishing. This seems like a legitimate concern.

To expand discussion, what about proactive tooling or enhancements to the Auth0 libraries or web dashboard to help strengthen defenses? Off the top of my head, similar to features provided by the startup, castle.io, and others.

I don't know if I'd still do it for consitency. If I'm using mostly the same CLI tools, there's no much to learn and less code to mantain.

I'd stil not use Gulp if it's not really neded, which in most cases isn't to be honest!

You'd just do it for consistency when calling gulp watch or gulp build?

For some of my projects the build process is pretty complex and gulp provides true value. However, after thinking about it more you could alway standardize on build through package.json script and if gulp was needed you have package.json refer to the gulp build.

That's true, and just call gulp from package.json :)

Hey,

Just as @rdegges said, I work on Auth0 so I'm a a little biased as well but I can give you some insights about Auth0 and tell you why I personally like it and why I joined the team.

- Pricing: I agree with you that it's not 100% ideal. To be honest, we've been fighting to make this clearer and easier. Our basic idea here is, don't charge somebody who's starting to do something. Charge them once they have enough users so that they can start getting money in, and only charge for Users that actually USE your site (Users that have entered your site in the last 30 days at least). But I'd love to get some feedback about it, if you're willing to :). Why do you think it's confusing and how would you change it?

- Features: I can enumerate all the features we have and all the ones I like, but the easiest way for you to decide what's best for you is just to create an account and try it out :). Put it in one of your projects. Follow the Quick start guide on https://docs.auth0.com/ and integrate it to your app. Let me know then if this was easy and straight forward enough for you :).

- Data Export: We don't have anything in the UI right now to show how you can export the data. However, our dashboard uses our API to show all of the information you see there, so you can just use our API to export all of the information in there. For example, for getting ALL of the users information to save it, just call https://docs.auth0.com/api#!#get--api-users and get it :).

- Why I joined Auth0: I work in Auth0 as a Developer Evangelist. The first thing you gotta know for this position is that if you don't like the product for the company you're joining, you're screwed :). What I love about it is that we use ALL standards (JWT, Open Id Connect, SAML, OAuth, etc.) which means that even if you don't like us after all, it's really easy to replace us. Also, we have TONS of stuff Open Source. I love Open Source and Openness. It's the way to go, and that's one of the main things I like about Auth0. Just go to our Github and check it out.

I don't want to make this message sound as I'm selling Auth0 to you. I haven't checked out Dailycred yet, but I do think Stormpath is also a good product. My final recommendation would be, just try all of them out, and join the one you feel more confortable with. If you have any feedback, please shoot me an email to [email protected] or [email protected].

Cheers :)

Hi, thanks for the response.

Part of my issue with your pricing strategy is that the way it is set out seems to almost go against the reason for (me) using a third party for user management, what I mean is that I just want users to be users, I don't care if they log in with social or enterprise etc, having to think about my user breakdown in that way is extra hassle and analysis that I really don't want to have to do. The more dials and knobs I have to think about for users the more complicated it gets for me. i.e. 'ok I use this plan if I have this many social users, but this plan if my users are enterprise users or this plan if etc'. And its kinda hard to tell what my user base will be until they turn up :/

Honestly ideally I want a 'dial' (or maybe 2 dials ,apps and users or whatever), whether that's API calls, unique users per month or whatever, I just want to easily know if I get <X> visitors then how much will it cost me.

I had to sit and think when I looked at your pricing page....I was trying to avoid doing that by throwing money at the problem :)

Hope that makes sense,

Paul

The proposal is that you can actually use that organization in an Angular app. It's just a proposition, as you can organize it however you want.

:)

What do you mean? Can you access the MySQL account and FTP account without User + Password?

If you're comfortable with that, then who am I to blow against the wind?

Hey thanks!

I finally found what was going on. And fixed it!

Thanks so much for the help. I actually used that tool :D.

Please give me your opinions!

I'm in Argentina, it's throwing 502 server error.

2 private repositories are awesome!