> 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.friedric...@gmail.com> wrote: > How can the database enforce password length? > > On Tue, Aug 18, 2020 at 1:08 PM Dave Neuman <neu...@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 <ocket8...@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. > > > > > >
