I have several passwords that I am forced to change much too often because the people in charge don't understand security very well. School, work, government sites/applications... they all do this.

The configuration to store their requirements is somewhat simple, there are only so many features (how often it expires, which patterns are allowed, disallowed, mandatory). It could be in an xml file, and Enpass could have a feature where it stored such a policy with feature.

The policy would explain to and allow Enpass to change the password without user intervention (no more nagging notifications "your password will expire in 11 days, do you wish to change it now"). It might even be the basis for a feature that, when large-scale password/database thefts occur, all Enpass users could have theirs automatically updated before the stolen passwords could be used.

Websites (the savvy ones anyway) might store their own password policy hidden in the markup itself, like so:

Quote

<link href="pw.xml" rel="password policy">

But until that caught on, Enpass users could craft their own. Other password manager software might actually make use of this (though, Enpass would be the first therefor proving itself the most innovative). Users could of course explicitly disable this feature if they did not wish to use it, just in case there's some early adopter website. Or, it could be used partially (since it would include the maximum allowable characters, Enpass could suggest that when registering a new password, or changing one manually).

This is a mockup of a password policy file, and might be missing a few things. It's larger than an actual working policy would be, because I list multiple options when only one would be chosen.

Quote

<password-policy>
    <endpoint>
        <protocol p="http">
            <url>https://somesite/password_change.php</url>
            <methods>
                <method>POST<method>
            </methods>
            <content-type>
                <mime>application/x-www-form-urlencoded</mime>
                <mime>multipart/form-data</mime>
                <mime>application/json</mime>
            </content-type>
            <fields>
                <field type="login">username</field>
                <field type="old">old_password</field>
                <field type="new">new_password</field>
                <field type="custom">some_crap</field>
            </fields>
        </protcol>
        <protocol p="command">
            <command>/bin/something</command>
        </protocol>
    </endpoint>
    <expiration>
        <nagging unit="week">10</nagging>
        <after unit="week">12</after>
    </expiration>
    <requirements>
        <no-captcha/>
        <minimum>
            <characters>8</characters>
            <lowercase>1</lowercase>
            <uppercase>1</uppercase>
            <numerals>1</numerals>
            <from n="1"><![CDATA[?,:;"'\/!@#$]]></from>
        </minimum>
        <maximum>
            <characters>32</characters>
            <change-attempts unit="day">1</change-attempts>
            <changes unit="day">7</changes>
        </maximum>
        <disallowed >
            <characters charset="utf-8"><![CDATA[<>.]]></characters>
            <initial-character charset="utf-8"><![CDATA[0123456789]]></initial-character>
            <terminal-character charset="utf-8"><![CDATA[0123456789]]></initial-character>
            <sequences>
                <sequence charset="utf-8"><![CDATA[word]]></sequence>
                <sequence charset="utf-8"><![CDATA[password]]></sequence>
            </sequences>
            <passwords>
                <login/>
                <dictionary>https://some.wellknown.external.dictionary.com/list.txt</dictionary>
            </passwords>
        </disallowed>
        <reuse>
            <never/>
            <after unit="day">180</after>
            <after unit="year">1</after>
            <after unit="successful-change">8</after>
        </reuse>
    </requirements>
</password-policy>

 

[crickets chirping]

Guess I didn't explain very well... this would let Enpass reset your passwords for you on those systems that require it every few weeks. You'd never even notice, it'd just happen for you. Or it could let it reset passwords for you if there's been a credible report of password databases being stolen.

Hi @BrigoNortensson,

Thanks for writing to us with your valuable suggestion.

Automatic password changer (APC) is something which is in our roadmap with all the milestones you mentioned (expiry date, password recipe with allowed characters), but the final milestone of APC is something which is tough and would be complicated due to offline nature of Enpass. Would Enpass be an online password manager, it'd have been easy job, having your data on its cloud and changing the passwords silently for some specific websites (with pre-defined password changing algorithms).  

But we do have plans to introduce APC later as a component of Password audit. 

Cheers!

That would actually be great

Are there any news on this feature?