On 8/25/2016 11:06 AM, Matthew Jones wrote:
> A salt and hash are much harder to use.

I agree with the discussion so this is just general comment.

Storing hashes would be better but that itself mainly protects against
easily seeing the plain text password.

Source code is available so the actual level of protection added by
salting and hashing itself is minimal :
- one can easily determine how salt is computed so password complexity
itself does not change due to salt.
- similarly how the password and salt are combined and hash algorithm
can be determined. I will assume proper hash algorithm is used.

The real protection with hash would come if the human side of the is
properly safe as well - long passwords (9+) that are not vulnerable to
dictionary attacks basically.

Above mostly applies to what would be built into EDB - using custom
plug-in that developer supplies for hashing/salting would make this more
complex in the field (one would hope) but also make EDB more complex.

Raul

Raul wrote:

> Storing hashes would be better but that itself mainly protects
> against easily seeing the plain text password.

That is indeed the main protection. Rather than being able to dump the
admin or other passwords and then use them, you have a lot more work to
be able to use them. Plus you might be able to re-apply them if someone
used the password for more than one system. Removing the plain text
does not solve everything, but it is a significant step.

--

Matthew Jones

Tim Young [Elevate Software] wrote:

> it can't be used with earlier versions of EDB

Ah yes. Perhaps a default in new databases and optional retro-applied.
I'm sure you'll make the right decisions as usual.

--

Matthew Jones

Roy Lambert wrote:

> Another issue is the ini file for EDBManager. What can be done about
> that apart from not let people use EDBManager or at least don't let
> them put admin level passwords in ye ini I don't know.

That is, I think, down to the user. On my dev PC, I store the password
for ease of operation. But on the server with the secure data, I don't.
The default user could be some basic rights user for making a backup or
something, but it is a user policy thing then, and for those who don't
care, it is easy. The key is that it isn't EDB that leaks the password.
Perhaps though if the default password is stored in plain text, it
should have a note on the config page to make that clear.

(One thing I have done in the past with ini file passwords is encrypt
them with a key that is in the registry. The key is created randomly if
it isn't there already. This prevents anyone from taking the INI file
to another computer and being able to automatically log in even though
they have the password in the file. For another system, I just put the
key in the INI file too. It wasn't really secure, but it prevents
someone from just reading the key when it was on screen for editing the
INI file. There are lots of ways to obscure the password against casual
observation, which is what most people will need.)

--

Matthew Jones

Roy,

<< Another issue is the ini file for EDBManager. What can be done about that apart from not let people use EDBManager or at least don't let them put admin level passwords in ye ini I don't know. >>

Yeah, it's a sticky wicket, for sure.  Hashes may help, but not for people that know what they're looking at, so the EDB Manager would have to also "know" a password used to encrypt the hashes, but then that would be available in the source code, as pointed out by Raul.

Tim Young
Elevate Software
www.elevatesoft.com

On 8/29/2016 4:26 AM, Matthew Jones wrote:
> That is indeed the main protection. Rather than being able to dump the
> admin or other passwords and then use them, you have a lot more work to
> be able to use them. Plus you might be able to re-apply them if someone
> used the password for more than one system. Removing the plain text
> does not solve everything, but it is a significant step.

I've been reading up on things like hashcat (offline password cracking
tool). It uses GPU speed of something as simple as dual GPU setup is
crazy and something one can easily find in decent gaming PC these days:

It can do SHA-512 at around 200M/s, SH-256 around 3000 M/s and SHA-1 at
8000 M/s.

Suffice to say i'm moved to using password manager for all my passwords.

Raul

Raul wrote:

> I've been reading up on things like hashcat (offline password
> cracking tool). It uses GPU speed of something as simple as dual GPU
> setup is crazy and something one can easily find in decent gaming PC
> these days:

Indeed - if someone has access to your computer, and determination, you
cannot defeat it. However even with that raw power (and you can buy
such in scale from Amazon...) you most likely end up with a string that
will generate the same hash. And if you care that much, stop wasting
time and grab the data in the database and ignore the password!

But the key here is appropriate protection. If you can just see the
admin or other password in plain text ever, then you don't need any
effort to break in. If you can get a hash, then you need to take some
"significant" effort to break in, that is, you have to care more than a
script kiddie.

This is also why the idea of having a "hash mode" column is useful, and
probably needed. Right now, you can do a SHA256 and be okay. But to
defeat the GPU crackers, you (I understand) have to run the hash a
number of times. The more times, the more secure because it takes
longer to repeat each time. But it costs more time for legitimate users
too, so you don't want to do it much. So you can migrate to stronger
methods and know which to apply using the mode column.

All of which effort varies according to how important the data is, and
how likely anyone will try to hack it.

--

Matthew Jones

On 8/29/2016 10:00 AM, Matthew Jones wrote:
> Indeed - if someone has access to your computer, and determination, you
> cannot defeat it. However even with that raw power (and you can buy

Actually just hashed password file - so if you replicate it site to site
that is a consideration to avoid it getting accidentally leaked.

> But the key here is appropriate protection. If you can just see the
> admin or other password in plain text ever, then you don't need any
> effort to break in. If you can get a hash, then you need to take some

Agreed

> This is also why the idea of having a "hash mode" column is useful, and
> probably needed. Right now, you can do a SHA256 and be okay. But to
> defeat the GPU crackers, you (I understand) have to run the hash a
> number of times. The more times, the more secure because it takes
> longer to repeat each time. But it costs more time for legitimate users
> too, so you don't want to do it much. So you can migrate to stronger
> methods and know which to apply using the mode column.

The hash calculation for something like SHA-512 is for all practical
purposes same as SHA-256 when you do it in your app (meaning once to
hash it or to check it) so i would not even bother with SHA-256 and go
straight to 512.

The "effort" to hack is actually very minimal - most of the password
file hacks (LinkedIn etc) are done using dictionary and not brute force
these days and that is very fast even with sha-512 (200 million attempts
per second).

Anyways, we're on the same page with all of this. I'm just saying doing
security right is hard so all of these things should be considered
assessing end product security.

Raul

Raul wrote:

> SHA-512 is for all practical purposes same as SHA-256

Sure, but the key is to repeat. First hit I found on what I'm talking
about:

http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

If you loop on the hash a few times, it strengthens the hash and costs
more to attack.

--

Matthew Jones

Tim, Matthew, Raul, Steve & lurkers all


There is at least one piece of good news. No one has yet suggested biometrics so I'm safe from having bits of my body removed and used as the password!


Roy