how safe is the *.com/Users login screen, regarding bruteforce attacks or similar?

is it possible to modify the users login screen in service studio (ie. to implement reCAPTCHA or TAN-Code)
or disable it for public access?

thank you!
Hi Enigma,

First of all, know that your cryptology has been broken by the Western allies in WW2 so you're probably unsafe to start with. ;)
(Just kidding)
I think you ask two good questions that only an Outsystems employee could answer.

For my side of the 'story'; I've created my own E-space, declared that as a "User Provider".
If you're already using the default user provider users, you could redirect that one to a new user provider and graduately modify your created E-spaces to use the "newer" userprovider.

I kick all of the other E-spaces to the User Provider E-space I created whenever a 'fresh session is opened'
(This by using the Security Exception which fires automatically when a registered login is expected;
and Storing the Entry URL in the On Session Start of each E-space; passing that as a value).
That gives you the option to store some nice logging values (IP, Username, Roles, Session Id etc).

If the user authenticates you kick him back to where he came from (Using the passed Entry Url parameter) to 'proceed' with the login.
The platform know's the users roles thanks to the successfull Login you should get from the created User Provider.
Should you maintain a similar structure you can easily check the connecting IP address and the login attempt count to counter brute force attacks.
You can also easily check the number of tries so you'd block an account or generate a recaptcha whenever a treshold (put that in as a Site variable) is reached.
Enterprise Manager was a nice start for user management but I think Lucio made user managment more "Simple" by switching to the 'flat' Users E-space only.
(And from many developers point of view; Simple is better)Anyhow; that way you're free to build your own security model.Anyhow; that way you're free to build your own security model.

Anyhow; that way you're free to build your own security model which is good, because it could also be
the start of a different kind of Authentication e.g. trough RSA token or a Fingerprint WebService device.
(Just depends on the effort you want to put in implementing a method differing from the default Username / Password combination)
This is the kind of reason why I do NOT use the stock login screens, and make my own. For internal usage they are fine, but for a public application they don't meet the needs.

I made it simple: I stored the number of invalid login attempts in Session, and when it got too high, I cut off all further attempts, stored a "cool down" time in Session, and didn't allow anything after the "cool down".

Others may prefer to disable the account entirely (and email the user to let them know) after a certain number of failed login attempts within a certain period of time.

I can agree with Justin on this matter.

It would be nice if we'd have a few nifty littly widgets that we'd only apply.
I think it's a good think to really know the security basics anyhow.


Hi Guys 

Is there someone who could guide me in the right direction with this question I am raising

I want to devlop an app that does not use OutSystems login credentials but instead uses the credentials for the system I am creating.

So instead of logging in with my outsystems credentials I would log in with the credentials my app specifies.

Would I have to create a totally new login screen and delete the default one?

Also, the authentication api that I need to get is in XMLRPC format

What options do I have? Please give examples of session tokens, session ids, authentication. Any videos or documentation will be great.


Tyrone -

1. Yes, you can do that. Authenticate with your 3rd party provider, then use the Login Action to do a login against a user without needing their password. You'll need to create a table that maps the external users to internal users. Or you can just have them all run as the same user, but that doesn't seem like a great idea.

2. You can modify the default one to meet your needs.

3. Use the Actions in HTTPRequestHandler to do POST/GET requests, construct the XMLRPC through text manipulations... or write an Extension to work with XMLRPC (the "Cook Computing" library for XMLRPC is great for .NET) and expose the needed actions in the Extension.