On 22.07.2017 11:54, Mark Rotteveel wrote:
On 21-7-2017 13:00, Alex via Firebird-devel wrote:
Yes, but SHA1 weakness becomes important only when password becomes
as long as hash, i.e. 20 bytes for sha1. Without enforcing users to
have long passwords replacing hash makes no sense.
That is
On 21-7-2017 21:55, Leyne, Sean wrote:
I think the point is, if a cracker has a security database, it can run
billions of SHA1 hashes per second using the same salt in a brute
force attack, because SHA1 is a fast (suitable to hash large files) algorithm.
With bcrypt, with is purposely slow,
On 21-7-2017 13:00, Alex via Firebird-devel wrote:
Yes, but SHA1 weakness becomes important only when password becomes as
long as hash, i.e. 20 bytes for sha1. Without enforcing users to have
long passwords replacing hash makes no sense.
That is unfortunately not true. The weakness that
> > I think the point is, if a cracker has a security database, it can run
> > billions of SHA1 hashes per second using the same salt in a brute
> > force attack, because SHA1 is a fast (suitable to hash large files)
> > algorithm.
> >
> > With bcrypt, with is purposely slow, the cracker can't
On 21.07.2017 14:43, Adriano dos Santos Fernandes wrote:
On 21/07/2017 08:00, Alex via Firebird-devel wrote:
Mark, this is interesting. I know bcrypt is very used by nodejs/expess
people and I even used it myself.
But what is more interesting, isn't Firebird still using these "not
suitable
On 21/07/2017 08:00, Alex via Firebird-devel wrote:
>>>
>> Mark, this is interesting. I know bcrypt is very used by nodejs/expess
>> people and I even used it myself.
>>
>> But what is more interesting, isn't Firebird still using these "not
>> suitable for passwords" hashes in recent versions?
>>
On 21.07.2017 13:38, Adriano dos Santos Fernandes wrote:
On 19/07/2017 15:51, Mark Rotteveel wrote:
In most cases original string (password) is not even stored and hashes
are used to check if a password matches a previously one.
The proposed hashes are **not** suitable for passwords; you
On 19/07/2017 15:51, Mark Rotteveel wrote:
>
>>
>> In most cases original string (password) is not even stored and hashes
>> are used to check if a password matches a previously one.
>
> The proposed hashes are **not** suitable for passwords; you shouldn't
> use a pure cryptographic hash for
On 19/07/2017 16:48, Mark Rotteveel wrote:
>
>> If we are not going to use hash plugins I'd vote for this syntax.
>
> I don't think this solution/syntax would disallow the possibility to
> handle this through plugins.
>
You are right. Algorithm name is a recognized at prepare time.
It can be
On 19/07/2017 15:42, Mark Rotteveel wrote:
>
>> HASH(X USING MD5) is self-documentary as well.
>
> Yes, it does improve readability.
>
> BTW: can I assume the hash functions will be binary (use OCTETS), and
> not hex encoded values?
>
Yes!
Adriano
On 2017-07-19 13:00, Adriano dos Santos Fernandes wrote:
On 19/07/2017 05:27, Dimitry Sibiryakov wrote:
19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
They will store hash on field of appropriate length for the given
hash
and index it.
On contrary, there is no point to store hash
19.07.2017 17:44, Leyne, Sean wrote:
Why do we need to extend the current function?
Why not create separate, built-in, functions for each hash type with names*
that align with the common algorithm name?
MD2()
...
MD5()
SHA0()
SHA1()
SHA_224()
...
SHA512_256()
...
SHA3_224()
...
SHA3_512()
> > We need to decide whether the algorithm name can be passed dynamically
> > (and thus be presented as "value" in the grammar) or must be
> > predefined (via a string literal or maybe token). The latter gives us
> > more flexibility regarding the result type.
>
> This is an interesting idea.
On 19.07.2017 14:07, Adriano dos Santos Fernandes wrote:
On 19/07/2017 02:29, Dmitry Yemanov wrote:
19.07.2017 01:32, Adriano dos Santos Fernandes wrote:
Algorithm name could define result length.
Yes, for constants.
We need to decide whether the algorithm name can be passed
On 19/07/2017 02:29, Dmitry Yemanov wrote:
> 19.07.2017 01:32, Adriano dos Santos Fernandes wrote:
>>
>>>
>>>Algorithm name could define result length.
>>
>> Yes, for constants.
>
> We need to decide whether the algorithm name can be passed dynamically
> (and thus be presented as "value" in
On 19/07/2017 05:27, Dimitry Sibiryakov wrote:
> 19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
>> They will store hash on field of appropriate length for the given hash
>> and index it.
>
> On contrary, there is no point to store hash value if its purpose is
> to speed up lookup only.
>
19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
They will store hash on field of appropriate length for the given hash
and index it.
On contrary, there is no point to store hash value if its purpose is to speed up lookup
only.
--
WBR, SD.
19.07.2017 01:32, Adriano dos Santos Fernandes wrote:
Algorithm name could define result length.
Yes, for constants.
We need to decide whether the algorithm name can be passed dynamically
(and thus be presented as "value" in the grammar) or must be predefined
(via a string literal or
Em 18/07/2017 16:58, Dimitry Sibiryakov escreveu:
> 18.07.2017 21:52, Adriano dos Santos Fernandes wrote:
>> It will be described as VARCHAR, so real length depends on the algorithm
>> used by the user.
>
> Index is built on full data length, not real one.
>
People will not be crazy to create
Em 18/07/2017 17:35, Vlad Khorsun via Firebird-devel escreveu:
>
> Algorithm name could define result length.
Yes, for constants.
> If alg name is passed as
> parameter, we could use maximum known length (of all known algs) at
> prepare time.
>
Maximum known length means if a new
18.07.2017 21:55, Adriano dos Santos Fernandes wrote:
Hi!
We have HASH function that returns a 64 bit integer. The algorithm is
bad and the result too small for a hash.
I propose to extend the same function with a second parameter with the
algorithm name.
> When only one parameter is passed,
18.07.2017 21:52, Adriano dos Santos Fernandes wrote:
It will be described as VARCHAR, so real length depends on the algorithm
used by the user.
Index is built on full data length, not real one.
--
WBR, SD.
--
18.07.2017 21:32, Dmitry Yemanov wrote:
Would it make sense to reserve more bytes, 256 or 1024 octets for example? Just to avoid
extending the result every five years...
Just take care not to overflow index limit.
--
WBR, SD.
On 18/07/2017 16:32, Dmitry Yemanov wrote:
>
>
>> When two parameters are passed, it will return a VARCHAR(64) CHARACTER
>> SET OCTETS. That's sufficient for a SHA-256, for example.
>
> Would it make sense to reserve more bytes, 256 or 1024 octets for
> example? Just to avoid extending the result
On 18/07/2017 16:34, Dmitry Yemanov wrote:
> 18.07.2017 22:00, Leyne, Sean wrote:
>>
>> Would this approach have any performance advantages over using UDFs?
>
> People hate writing UDFs for common tasks. And IMHO getting a robust
> hash belongs to this category.
>
Moreover, we already have HASH
18.07.2017 22:00, Leyne, Sean wrote:
Would this approach have any performance advantages over using UDFs?
People hate writing UDFs for common tasks. And IMHO getting a robust
hash belongs to this category.
Dmitry
18.07.2017 21:55, Adriano dos Santos Fernandes wrote:
We have HASH function that returns a 64 bit integer. The algorithm is
bad and the result too small for a hash.
Yes, and we have CORE-4436 with related complains.
I propose to extend the same function with a second parameter with the
> We have HASH function that returns a 64 bit integer. The algorithm is bad and
> the result too small for a hash.
>
> I propose to extend the same function with a second parameter with the
> algorithm name.
>
> When only one parameter is passed, things works as now.
>
> When two parameters
28 matches
Mail list logo
