Passwords do not have minimum level of security

[gerald626]

Steps to reproduce

1. Create new user with 1 character password
2. Login with said account
3. Profit???

   Expected behaviour

Admins should be able to set the minimum password security requirements (max/min characters, upper/lower case, special characters, etc...

Actual behaviour

Passwords of 1 character are allowed.

Server configuration

Operating system: Linux SERVER 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Web server: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.3 OpenSSL/1.0.1f

Database: mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3

PHP version: PHP/5.5.9-1ubuntu4.3

ownCloud version: (see ownCloud admin page) ownCloud 6.0.1+dfsg-1ubuntu1 (Debian) (stable)

Updated from an older ownCloud or fresh install: Fresh

List of activated apps: Default

The content of config/config.php:

<?php $CONFIG = array ( 'instanceid' => '', 'passwordsalt' => '', 'datadirectory' => '/var/owncloud/data', 'dbtype' => 'mysql', 'version' => '6.0.0.16', 'appstoreenabled' => false, 'appspaths' => array ( 0 => array ( 'path' => '/usr/share/owncloud/apps', 'url' => '/apps', 'writable' => false, ), ), 'dbname' => 'owncloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc', 'dbuser' => '', 'dbpassword' => '', 'installed' => true, 'maxZipInputSize' => 838860800, 'allowZipDownload' => true, );

Are you using external storage, if yes which one: local/smb/sftp/... No

Are you using encryption: yes/no Yes

Client configuration

Browser: Chrome 37.0.2062.103 m Operating system: Windows 7 64-bit

Logs

Web server error log

Not applicable

ownCloud log (data/owncloud.log)

Not applicable

Browser log

Not applicable

[karlitschek]

@lukasreschke. What do you think? The challenge is to stay compatible with external user managements like ldap

[LukasReschke]

Yes. This is something that we should have in the future but I don't see an immediate need for it right now. It would currently just be "yet another hack that we need to maintain without really increasing your security".

In the real world users tend to just increase numbers (e.g. summer14! => summer15!) in their passwords or write it down. Which usually would not really increase the overall security.

Implementing this properly would require from my point of view:

• Adding a password expiration policy
• Adding an easy to use password policy tool
• Add a password change page in case the password expired.

This is not something that I would consider for stable7. stable8 might be realistic.

This also would require that the users have to change the password on all their connected devices on their own. I'd therefore prefer to habe OAuth2 for this so that the user does not have to change anything. (if he believes a token has been leaked he can reset the single token)

[gerald626]

In the real world users will use the number '1' as a password if they can. On Sep 6, 2014 4:26 AM, "Lukas Reschke" notifications@github.com wrote:

Yes. This is something that we should have in the future but I don't see an immediate need for it right now. It would currently just be "yet another hack that we need to maintain without really increasing your security".

In the real world users tend to just increase numbers (e.g. summer14! => summer15!) in their passwords or write it down. Which usually would not really increase the overall security.

Implementing this properly would require from my point of view:

• Adding a password expiration policy
• Adding an easy to use password policy tool
• Add a password change page in case the password expired.

This is not something that I would consider for stable7. stable8 might be realistic.

This also would require that the users have to change the password on all their connected devices on their own. I'd therefore prefer to habe OAuth2 for this so that the user does not have to change anything. (if he believes a token has been leaked he can reset the single token)

— Reply to this email directly or view it on GitHub https://github.com/owncloud/core/issues/10901#issuecomment-54706303.

[h-2]

:+1: this is really necessary!

[sbelov1]

@bboule @craigpg We have a large prospect asking for this as a hard requirement. @MTRichards do we have this on the roadmap?

PS Opening FT for this in SFDC.

[MTRichards]

Which part is missing this - server? Or sharing link?

[sbelov1]

@MTRichards Sharing via link. They're using AD for user auth.

[MTRichards]

It is in consideration for 8.1.

What password options do they want for strength? Trying to get to minimum viable product here. Upper, lower, special character, number, min length?

How do they want to set these options?

Or is something simple like min length alone enough?

[sbelov1]

@MTRichards checking with the prospect...

[MTRichards]

Thanks! Feature research.

[ma-schmid]

@MTRichards @bboule very large prospect has the same requirement: as an example, they provided a screen shot of a simple configuration for public link passwords

[DeepDiver1975]

as an example, they provided a screen shot of a simple configuration for public link passwords

simple? LOL @jancborchardt will love this "easyness"

[jancborchardt]

Yeah, sorry but ridiculous password requirements are the most annoying UX on the internet.

At most this can be done as a separate app which will definitely not be shipped by default.

[bboule]

Hey guys it sounds like we have a few large potential users that are asking for this, and it sounds like we are not inclined do do this in the product? Am I reading this correctly, this would need to be developed as a separate app @craigpg do you see this as a potential consulting engagement. I guess my point here is the requirement is not going to change just want to figure out how to get there?

[MTRichards]

This is on the list for ownCloud 8.2. The screenshot above is simply to outline the options that need to be covered.

@bboule @CaptionF As discussed on the List. @cmonteroluque for your reference. @jancborchardt is there an option that gets us close you would consider "visually appealing"? Can't have confidential data hanging out there with a password of "l".

[DeepDiver1975]

We basically can add a feature in core allowing some kind of callback which allows any other code to verify the password. Some super fancy UI to specify password restriction can be implemented as an isolated app.

[jancborchardt]

I mean – the example screenshot above already is quite close to how visually appealing you can make such an interface.

The thing I meant here is that from a high-level standpoint that this should be a separate app for sure, not in core by default. (As Thomas just said seconds ago above.)

[MTRichards]

I like that. Gives us what we need without cluttering the interface unnecessarily.

@DeepDiver1975 What would it take to do what you said there, to create the ability to do this?

[bboule]

@sbelov1 @CaptionF does the 8.2 timeframe create an issue? How does this impact the Opps?

[sbelov1]

@bboule It doesn't impact us any longer as we've lost the prospect.

[ma-schmid]

This is critical to their going live date and with that to deal closing time! need to be included earlier! Matthias Please excuse typos as this mail was created on smart device

bboule notifications@github.com schrieb:

@sbelov1@CaptionFdoesthe8.2timeframecreateanissue?HowdoesthisimpacttheOpps?ReplytothisemaildirectlyorviewitonGitHub.

[h-2]

Guys, who cares about fine-tuning, just include a slider for minimum password strength 0-5 and then make up your own rules for the steps. At least there would be some mechanism...

[bboule]

@cmonteroluque @MTRichards Please see CaptionF comment perhaps we can discuss alternatives to 8.2 as this seems to be critical? Perhaps we can discuss offline?

[atroxix]

Something related to this is implemented in 8.2 Enterprise now (Password Policy)?

[bboule]

@cmonteroluque @MTRichards This seems to be in the backlog with no one assigned @CaptionF is this no longer critical?

[MTRichards]

For transparency sake, the intent from our side is to point admins to a true authentication mechanism, such as a directory, when enforcing password complexity. Things like strength of the password itself, as well as failed login attempt lockouts and so forth are intended to be provided by a solution that specializes in providing these sorts of services.

[ghost]

Agree with @MTRichards

[PVince81]

@rullzer pointed out that this might already be covered by the password policy app ? Or is it missing something ?

[PVince81]

Ok, just remembered that the password policy app is only for link share passwords. It doesn't affect user entered passwords.

[PVince81]

Closing in favor of https://github.com/owncloud/core/issues/10901 which is a similar topic

[Pazu]

@PVince81, isn't this #10901?

[PVince81]

Something went wrong with my clipboard and I pasted the wrong number. Just went through the searches again and couldn't find the other one. I think it was something about generating passwords or so.

Anyway, thanks for pointing out, reopening.

[robarchibald]

Dovecot does password policy enforcement through an external API call. There are a lot of benefits to doing it this way including the fact that ownCloud doesn't have to design or implement the myriads of different password policies that every different enterprise could want. If ownCloud were to simply support an API call, there could be a truly SIMPLE configuration UI to point to an API server with a few parameters. Much easier! I vote for something truly "simple" like this. https://wiki2.dovecot.org/Authentication/Policy.

With this in place the authentication policy service could: 1) Block any attempt to enter in a password that doesn't meet the administrator's defined complexity rules. Administrators could define whatever schemes they want in their API. 2) Block due to a locked account that has exceeded the number of failed password attempts or any other administrator-defined reasons. This can include accounts that are locked for services other than ownCloud. 3) Block an IP address that is brute-force trying multiple accounts

[karakayasemi]

We have app for this purpose: https://github.com/owncloud/security, I guess we can close this.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.