[SR-Users] Size of passwords fields in db

[Fred Posner]

On 10/06/2016 05:43 AM, Daniel-Constantin Mierla wrote:
> On 05/10/16 16:35, Fred Posner wrote:
>> On 10/05/2016 10:25 AM, Daniel-Constantin Mierla wrote:
>>> 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.
> 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...

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.

>>
>> 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
> 

--fred