Sorry, you got taught wrong. Security is about the whole system, not one
piece. Hash based security is vulnerable during password exchange, which a
slow hash doesn't fix.
Internet connections typically pass through a dozen routers, any of which
could be configured to mount a man in the middle
On 07/26/2015 10:36 PM, Jim Starkey wrote:
The bottom line is this: If you are going to change the password hash,
you are going to invalidate all existing passwords. But rather than
start over with an already flawed architecture, punt on storing
passwords at all and go exclusively with SRP.
Internet connections typically pass through a dozen routers, any of which could
be configured to mount a man in the middle attack. The most important thing to
get right is the security handshake. If that's weak, nothing else matters.
I agree. I, and I believe the original proposal, was mostly
On 07/25/2015 12:12 PM, Mark Rotteveel wrote:
I am getting to a point where I want to implement the protocol 13 and
new authentication and encryption of Firebird 3 in Jaybird. I'd like to
know what was changed for protocol 13, and details on how authentication
and encryption work, and how I
Not saying I want/need that for the moment, but you did ask for
suggestions. And yes, the exact purpose of slow hashing is to make
bruteforce attacks harder both with legit client attempts to authenticate,
and when/if the user database is compromised. The latter might be a more
valid reason to
From: Vlad Khorsun
Now I have problem on customers site where every day OIT get stuck.
...
OIT is the number of the oldest non-committed transaction *minus one*.
I.e. if you look for OIT number at the trace log, then you found not what
you really need. Look for OIT + 1.
Thanks, that
On Sun, Jul 26, 2015 at 5:15 PM, Vlad Khorsun wrote:
Or is there a reason to ignore those higher bits for the facility
and code?
I have no idea why ENCODE_ISC_MSG written in this way.
CLASS_MASK seems to not be used anywhere, or at least I can't
On 7/27/2015 11:31 AM, Ann Harrison wrote:
27.07.2015 1:24, Ann Harrison wrote:
Firebird was based on InterBase which was based on Rdb/ELN, an
implementation of DEC's [standard(!)] relational
interface. As part of DEC's VAX software empire, DSRI used
DEC's error
On 7/27/2015 8:35 AM, Alex Peshkoff wrote:
On 07/26/2015 10:36 PM, Jim Starkey wrote:
The bottom line is this: If you are going to change the password hash,
you are going to invalidate all existing passwords. But rather than
start over with an already flawed architecture, punt on storing
On Thu, 23 Jul 2015 09:50:23 +0200, Stefan Heymann
li...@stefanheymann.de
wrote:
In the FB3 Release Notes the chapter about Increased Password Length
speaks of a maximum of 20 *bytes*. The second blue box in this chapter
then asks:
Why is the password effectively limited to 20 *characters*?
27.07.2015 1:24, Ann Harrison wrote:
On Sun, Jul 26, 2015 at 5:15 PM, Vlad Khorsun wrote:
Or is there a reason to ignore those higher bits for the facility and
code?
I have no idea why ENCODE_ISC_MSG written in this way.
CLASS_MASK seems to not be used
On Sunday, July 26, 2015, Jiří Činčura j...@cincura.net wrote:
Personally, I've recently started using (mostly for kicks) things like
https://en.wikipedia.org/wiki/Scrypt
https://en.wikipedia.org/wiki/Bcrypt
https://en.wikipedia.org/wiki/PBKDF2
I suppose the option to tune them in the
12 matches
Mail list logo
