#31358: Increase default password salt size in BasePasswordHasher.
--------------------------------------+------------------------------------
Reporter: Jon Moroney | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Utilities | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Florian Apolloner):
Hi, sorry for the late reply but I am swamped with work recently and lost
track of this. I'll try to answer the questions as good as possible.
> I'm not opposed to implementing a decode function, but I'm not sure I
understand how it would differ from the safe_summary function.
The intention is simple, `safe_summary` is ment for display, ie it calls
`mask_hash` and similar functions which make it look like
`a5bcd**********` (literally). A custom password hasher might even go as
far as actually truncating the hash that is shown, so the data you get
back from `safe_summary` as of now would not contain the actual decoded
data. But due to backwards concerns we cannot change that function.
> clear breaking change
Yes, they will have to add this new function unless we can come up with a
better idea (ie if decode is not implemented the default salt size will
not increase but start raising warnings)
> It makes me think that the encoded result could be truncated and if we
consider third party hashers then we must consider truncated DB entries.
I'm not sure if this is a real issue or not, but the 128 character limit
does raise an eye brow to me.
The 128 character limit comes from the size of the database column in the
db, if needed we could increase that. That said the database should not
have truncated entries because any non-broken database will throw an error
if you insert >128 characters into a 128 char field.
> Sounds reasonable, but what does the decode function look like?
A stub (or probably not implemented at all in the base hasher for the
transition period) which returns dict[str, any]. Ie the iteration count
would be an integer. Good question regarding bytes vs base64, but I think
it should be okay if we return the base64 values here instead of going
back to the raw bytes.
--
Ticket URL: <https://code.djangoproject.com/ticket/31358#comment:22>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.9c4c675c53984a343bbe2b1720e8f37d%40djangoproject.com.
