Re: [EXTERNAL] Re: Petition to restrict password minimum length

["Gray, Jonathan" <Jo...@comcast.com>]

Keep in mind the PostInstall perl script might be doing it differently too.

Jonathan G

On 8/18/20, 12:00 PM, "ocket 8888" <oc...@gmail.com> wrote:

    > We could probably get away with doing it over minor versions too.

    I wouldn't be opposed to that either. If it mattered. Because:

    > How can the database enforce password length?

    It... seems like it can't. I just looked and it appears that those are
    encrypted in the API and stored at a fixed length. That means the user
    password I'm thinking of is being inserted into the database directly...
    Disregard!

    On Tue, Aug 18, 2020 at 11:18 AM Eric Friedrich <er...@gmail.com>
    wrote:

    > How can the database enforce password length?
    >
    > On Tue, Aug 18, 2020 at 1:08 PM Dave Neuman <ne...@apache.org> wrote:
    >
    > > Seems reasonable however I don't think we need to wait for major version.
    > > We could probably get away with doing it over minor versions too.
    > >
    > > On Tue, Aug 18, 2020 at 11:00 AM ocket 8888 <oc...@gmail.com> wrote:
    > >
    > > > Currently, Traffic Portal restricts the passwords entered to a minimum
    > > of 8
    > > > characters. This restriction is not mirrored in the database (and
    > > possibly
    > > > not in the API, but that can be fixed at the same time as the db if
    > > that's
    > > > the case). I propose that we add this restriction to prevent
    > potentially
    > > > wildly insecure passwords from existing for Traffic Ops clients.
    > > >
    > > > This would entail including a notice in the 5.0 release, probably in
    > the
    > > > changelog, one or four places in the documentation, and possibly
    > another
    > > > email to the users list after the 5.0 - to notify - and 6.0 - to
    > remind -
    > > > releases. Then, a migration can be added to 6.0 to restrict password
    > > length
    > > > at the database level, giving users a full major upgrade cycle to make
    > > > their data compliant with the new restrictions.
    > > >
    > >
    >

Re: [EXTERNAL] Re: Petition to restrict password minimum length

[Robert O Butts <ro...@apache.org>]

Yeah, TO puts the one-way secure hash in the DB, the DB can't enforce
anything about it.

I don't think we want to change that. It's possible to have Postgres do the
hash, but we don't want to be sending plaintext passwords over the wire.
Database validation is always good, but it's worse than the alternative
here.


On Tue, Aug 18, 2020 at 1:07 PM Gray, Jonathan <Jo...@comcast.com>
wrote:

> Keep in mind the PostInstall perl script might be doing it differently too.
>
> Jonathan G
>
> On 8/18/20, 12:00 PM, "ocket 8888" <oc...@gmail.com> wrote:
>
>     > We could probably get away with doing it over minor versions too.
>
>     I wouldn't be opposed to that either. If it mattered. Because:
>
>     > How can the database enforce password length?
>
>     It... seems like it can't. I just looked and it appears that those are
>     encrypted in the API and stored at a fixed length. That means the user
>     password I'm thinking of is being inserted into the database
> directly...
>     Disregard!
>
>     On Tue, Aug 18, 2020 at 11:18 AM Eric Friedrich <
> eric.friedrich84@gmail.com>
>     wrote:
>
>     > How can the database enforce password length?
>     >
>     > On Tue, Aug 18, 2020 at 1:08 PM Dave Neuman <ne...@apache.org>
> wrote:
>     >
>     > > Seems reasonable however I don't think we need to wait for major
> version.
>     > > We could probably get away with doing it over minor versions too.
>     > >
>     > > On Tue, Aug 18, 2020 at 11:00 AM ocket 8888 <oc...@gmail.com>
> wrote:
>     > >
>     > > > Currently, Traffic Portal restricts the passwords entered to a
> minimum
>     > > of 8
>     > > > characters. This restriction is not mirrored in the database (and
>     > > possibly
>     > > > not in the API, but that can be fixed at the same time as the db
> if
>     > > that's
>     > > > the case). I propose that we add this restriction to prevent
>     > potentially
>     > > > wildly insecure passwords from existing for Traffic Ops clients.
>     > > >
>     > > > This would entail including a notice in the 5.0 release,
> probably in
>     > the
>     > > > changelog, one or four places in the documentation, and possibly
>     > another
>     > > > email to the users list after the 5.0 - to notify - and 6.0 - to
>     > remind -
>     > > > releases. Then, a migration can be added to 6.0 to restrict
> password
>     > > length
>     > > > at the database level, giving users a full major upgrade cycle
> to make
>     > > > their data compliant with the new restrictions.
>     > > >
>     > >
>     >
>
>