6 Oct
2016
6 Oct
'16
7:47 a.m.
On 10/06/2016 05:43 AM, Daniel-Constantin Mierla wrote:
--fred
On 05/10/16 16:35, Fred Posner wrote:
I guess there's really no cost to increasing it to 128 / sha 256 and
give ourselves some good time before we need to reconsider. The storage
cost will still be based on the actual value used and not the size
constraint; giving people options.
On 10/05/2016 10:25 AM, Daniel-Constantin Mierla
wrote:
That refreshed my mind that we have now support for sha
256, which means
that ha1 fields need to be 64 (and they are now), but wondering if
someone will want to have and add sha 512 any time soon, which means the
ha1 fields need to be 128... Hello,
writing here to decide on a topic opened by pull request 779:
- https://github.com/kamailio/kamailio/pull/779
what would be a fair size for db column storing a password that one
would like to have for proper security?
I would like to make it consistent over all tables that have a password
column by defining a xml entity for the size of these columns. The pull
request suggests 64 chars, has anyone other opinions on making it larger
or smaller?
If they are defined varchar, then should not be a problem of allocated
size, so we can go with 128 if someone feels it worth doing larger now
so we don't have to change it again in the near future.
This change is about db schema, the modules I expect to work with
allocated strings (or have length checks) in this case and should not be
affected.
Cheers,
Daniel
Although I can see why someone might consider the need for larger than
varchar 64, I really don't see a need for it. Assuming if you needed
more characters it would probably be time to use additional
authentication methods.
I believe Polycom still max's out at 32.
I haven't looked at phones
restrictions on this, but I saw old devices
accepting only digit based passwords... hopefully not many out there at
this moment.
A stronger auth method would be highly desired, but I guess a lot of
people are restricted by deployed devices.
Cheers,
Daniel