A question about IT security with YunoHost

Discuss
,
1

Hello everyone,

I have a question about IT security with YunoHost and would like to know what you think about it.

Normally, an IT security rule is that you should always choose a different password for each portal, forum, shop and the like. In this context, how do you rate YunoHost’s Single Sign On?

With YunoHost I have exactly ONE password for various APPs. Namely the login to YunoHost. I then have immediate access to all my APPs available there via SSO. And WITHOUT any further security barriers.

For daily use, this is of course very convenient for the user. But also for data thieves.

Or am I missing an important aspect? Is it just the usual balancing act between security and convenience? How do you see it? I’m curious to hear your views on the subject.

Thank you very much and best regards
Tinder

2 Likes
2

I guess you could wonder the same kind of stuff regarding Google stuff where they have a single sign-on accross youtube, gmail, google agenda, google docs etc …

Security is a complex matter and you could somehow argue that having “different password for each internet service” is bad because, factually, most people do not use password managers and then they write every passwords on postit or notebook they leave at their desk, or they reuse the same password everywhere which has other drawbacks. At least with single sign on, there’s only one endpoint to secure, not every single service etc… I’m sort of playing the devil’s advocate here, I don’t have a strong opinion regarding “SSO is better” or “SSO is worse” in terms of security.

With that said, there’s definitely improvements that could be made to YunoHost current SSO, such as using OIDC/SAML and supporting 2FA. But both these things are not trivial for various reasons.

Also yeah, of course everything in security is always a trade-off with other things … the first thing to remember is that security is not a “boolean state” like “XY is secure : true/false”, it’s a process transversal to everything and in particular human habits, convenience, threat models, etc … Also mandatory xkcd

4 Likes
3

@Aleks Thank you very much for your many thoughts on my question. Yes, in the end this probably also applies to google. Although I don’t use google and I like yunohost much better despite - maybe because of? - the difference in size :wink:

How do you mean that there is only one endpoint and not every service has to be secured individually? The APPs are all individual services and could be attacked separately. Especially if the services have to be public in order to be accessible by others from the Internet (such as nextcloud or Fediverse APPs), all APPs must be secured. Right?

It’s completely ok that there are still a few things to improve at YunoHost. Rome wasn’t built in a day either :slight_smile:

I wonder which course makes more sense in principle. I’m also not clearly in favour of or against SSO. That’s why I thought I’d have to talk to people who are a bit more familiar with SSO than I am.

4

@tinder

This is an old subject, but this is a forum and as such not bound to short time.
It can be discussed endlessly :wink:

All is about Trust.

Let’s just consider why there is SSO : because it is cumbersome to handle many password, and even to enter them somewhere, SSO is what users wants.

It is a tradeoff between convenience and security based on trust.

If you don’t set SSO, users will nevertheless tentatively use same password for all your services :wink:

Is it safe to have one password for all services ?
General answer is no.
This covers who or what organisation you give your credentials ( password ), those can impersonate you.
Nobody should share its password with anybody else, a password is actual -you- . But it happens actualy that intial setup requires that you share it with authentication service first.

So a strong advice is to not use same password for yunohost than other external services.

Nobody should consider a service as a conveniency and that can receive a short password since it is only for buying flowers by example. All services can have bad actors and it can be really difficult to know what a bad actor can do with even a small piece of information.

Now within yunohost is that an issue to have same password for all services ?

In case of yunohost, having SSO or not, there is an administrator -you- that can do whatever it wants :wink:
If applications have really different usage some are conveniency and other contains really important things, security should be understood as the one for the most exposed one.
Then if it is required to have a second factor and application can do it by itself, so should the SSO do it first for all services.

And finally if usages are really different it is still possible to have multiple yunohost instance, so each with dedicated passwords.

SSO is about Authentication first then authorization comes after.
So yes there is a unique SSO password, just like you have a unique ID card. Here password is proof that your are who you tell, then it is authentication.
SSO is used everywhere,when system remembers who you are. Starting from Microsoft login with active directory long time ago, and even unix login can be seen as sso, since you don’t have authenticate for each program/application you use, once you get a user id on your system you are authenticated.
So SSO has a context of authentication, a perimeter, for Yunohost SSO perimeter is yunohost system ie one host, but for Google, Microsoft, GitHub and so on this perimeter is full web, it is just a matter of application to trust the emitter of SSO. One SSO emitter is trusted, application trust its decision about authentication.
In case of external SSO services, password or whatever tools used to authenticate you are not under control of application, so application can’t reuse those to get more right than what SSO service decides.
In case of yunohost, depending on integration, application might not have access to user password.

Once system know who your are it does authorization.

In yunohost itself application access through portal is authorized based on groups.
It can give application information about which user is connecting if application uses yunohost SSO, what is not always the case.
Then each application does it own mess :slight_smile: Application can use yunohost SSO it depends on how it is integrated. In any case from the user information each application select what rights/roles user has. Application can decide to refuse a user even if in application group.
Applications can requires additional second factor too.

Security relies too on browsers, those are where sessions are kept, mostly cookies, and authorization is bound to those cookies, same as application token. This is another subject, but it is important to know it. When applying security practices you should even have different Profile run in different browser for very different activities, like professionnal matter, family matter and nudes pics ( yes that one was to wake you up on that long answer ).

And for passwords there are password safe ( keepass by example), that can generate for you password, in that case SSO is somehow the master password of your password safe.