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
On 10/05/2016 10:25 AM, Daniel-Constantin Mierla wrote:
Hello,
writing here to decide on a topic opened by pull request 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.
--fred
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:
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 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
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:
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
On 06/10/16 13:47, Fred Posner wrote:
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:
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.
To conclude: I increased the size of password fields to 64 and hashed fields to 128.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Fred Posner