I'm going to use an external module for writing/reading an encrypted user update file, which is called by a job.

= Steve

Steve


I'd either do that or add the password to your user table making sure it was encrypted

Roy Lambert

Roy Lambert wrote:

> I was loath to suggest anything like that because I don't know a way
> to export a table in an encrypted fashion so the passwords are there
> in the clear.

Ummm, do I read that as EWB is storing passwords as-is? That's a no-no
in this modern era. I hope that Tim has converting to salt and SHA256
hash on the early to-do list. (Probably with a "mode" column to allow
conversion from old to new and allow future adaptations to new
algorithms).

--

Matthew Jones

Matthew


>Ummm, do I read that as EWB is storing passwords as-is? That's a no-no
>in this modern era. I hope that Tim has converting to salt and SHA256
>hash on the early to-do list. (Probably with a "mode" column to allow
>conversion from old to new and allow future adaptations to new
>algorithms).

Did you get confused about which forum this was

ElevateDB, as far as I know, stores user details in the configuration file which is encrypted on disk. You can ask for specific tables to be encrypted and BACKUP respects the encryption (which means it can't compress data as well as I'd like). My response was in respect of EXPORTing tables and that's done in the clear - makes sense otherwise you'd not be able to use them elsewhere.

I have no idea what EWB does but I suspect its a bit like with EDBManager's and edbsrvr's  ini files - your responsibility.

Roy Lambert

Roy Lambert wrote:

>  My response was in respect of EXPORTing tables and that's done in
> the clear - makes sense otherwise you'd not be able to use them
> elsewhere.

I got the right forum, wrong name. No password database should be
exportable in the clear in 2016. Unless you are a bank with big
security apparatus in place, and even then it isn't necessary. The key
is that you should hash the password with salt, and store those two.
You can move them both to use them elsewhere. As I say, it is typical
to have a "mode" column too so that you can tell what to do with them,
so you might have mode 1 as "plain stored password" and mode 2 as
"hash256withSalt". And then mode 3 as "fixedHash256" or something.

To be able to get a plain text password version at all is a security
risk, particularly for the database admin password when the decryption
key will be sitting on disk with it...

(The risk may be low, but it is there nowadays, so it is worth solving.
I do these things so I can say I was using best practice for when
something gets hacked...)

--

Matthew Jones

Matthew


>I got the right forum, wrong name.

My brain's going like that as well <vbg>

>No password database should be
>exportable in the clear in 2016.

I disagree with this. More from a view of its my data and I'll do what I want with it than from a security viewpoint. Being fair and sensible. ElevateDB has enough security in place that if you reach a point where its possible to export the users table with passwords its already to late to worry. A pencil, paper and enough time to write will do the job.  If the programmer chooses to build a feature in to do that for any old user (note STeve hasn't)  then that's his problem not the databases.

>Unless you are a bank with big
>security apparatus in place, and even then it isn't necessary.

That statement makes my mouth taste bad. Mixing banks and security in one sentence is just plain wrong. Remember these are the organisations that are so good at security that literally billions of pounds can be stolen before they notice (SWIFT anyone), if they do; who don't have a mechanism to tell if the ATMs have been tampered with.

>The key
>is that you should hash the password with salt, and store those two.
>You can move them both to use them elsewhere. As I say, it is typical
>to have a "mode" column too so that you can tell what to do with them,
>so you might have mode 1 as "plain stored password" and mode 2 as
>"hash256withSalt". And then mode 3 as "fixedHash256" or something.
>
>To be able to get a plain text password version at all is a security
>risk, particularly for the database admin password when the decryption
>key will be sitting on disk with it...

To create a new user, or maintain a users password, which is what this was required for requires the password to be in the clear at the point the user is created or the password modified. Whatever you do that is inescapable unless Tim changes how ElevateDB works. You are therefore guaranteed to have something sitting on disk, at multiple locations, to decrypt the password however stored. OK I can come up with alternative stratagems but they would require me to build my own password management system.

>(The risk may be low, but it is there nowadays, so it is worth solving.
>I do these things so I can say I was using best practice for when
>something gets hacked...)

The bit you seem to be missing is "proportionality". Yes I want my on-line banking secure (but I'm still not installing Rapport) but I don't care about my free subscription to The Register.

Sorry you hit my rant button. I've got it under control now.

Roy

Roy Lambert wrote:

> To create a new user, or maintain a users password, which is what
> this was required for requires the password to be in the clear at the
> point the user is created or the password modified. Whatever you do
> that is inescapable unless Tim changes how ElevateDB works. You are
> therefore guaranteed to have something sitting on disk, at multiple
> locations, to decrypt the password however stored.

Sorry, but this is wrong. The password should never be stored as-is.
The key is that to log in, you send the password and that is combined
with the salt on disk, and you see if the hash matches. If so, you are
authenticated. The key therefore is that with the many passwords you
have, none are ever stored, and thus to attack the system you have to
have a long term monitor. Most attacks though get access to the
computer remotely, and dump the database tables. To have plain text
passwords in that data is not good. Nowadays, it is irresponsible
programming. Yes, I have a pet rant on this, but then I see how many
stupid mistakes are still made on security.

Now, how you choose to organise your database and tables is up to you -
I don't care if you store the passwords in all caps and show them on
the main screen of your application. But I depend on the EDB security
for my web shop, and to have a way for someone to get a dump of the
administrator password in plain text is not something I like the sound
of. My code is such that the application uses a restricted rights user,
and the admin password is never stored on the server. Despite the
encryption in the EDB code, it should not be stored in plain text. It's
not hard to fix and do properly.

To go back to the bank reference, it is like me keeping my PIN secure,
and then finding the cash is all sitting behind the tellers in big
piles, not held in a safe. 8-)

Anyway, enough said, this isn't a major flaw, just something that would
be good to have tidied up.

--

Matthew Jones

Matthew


>> To create a new user, or maintain a users password, which is what
>> this was required for requires the password to be in the clear at the
>> point the user is created or the password modified. Whatever you do
>> that is inescapable unless Tim changes how ElevateDB works. You are
>> therefore guaranteed to have something sitting on disk, at multiple
>> locations, to decrypt the password however stored.
>
>Sorry, but this is wrong.

You may disagree with the approach but its factually correct (or at least until I'm corrected by Tim I believe it is)

>The password should never be stored as-is.
>The key is that to log in, you send the password and that is combined
>with the salt on disk, and you see if the hash matches. If so, you are
>authenticated. The key therefore is that with the many passwords you
>have, none are ever stored, and thus to attack the system you have to
>have a long term monitor. Most attacks though get access to the
>computer remotely, and dump the database tables. To have plain text
>passwords in that data is not good. Nowadays, it is irresponsible
>programming. Yes, I have a pet rant on this, but then I see how many
>stupid mistakes are still made on security.

I don't disagree for anything requiring a high level of security. I do agree with you - most of the password dumps I've read about come from SQL injection.

>Now, how you choose to organise your database and tables is up to you -
>I don't care if you store the passwords in all caps and show them on
>the main screen of your application. But I depend on the EDB security
>for my web shop, and to have a way for someone to get a dump of the
>administrator password in plain text is not something I like the sound
>of. My code is such that the application uses a restricted rights user,
>and the admin password is never stored on the server. Despite the
>encryption in the EDB code, it should not be stored in plain text. It's
>not hard to fix and do properly.

I think I'm confused now. Only allowing users restricted access prevents them from exporting the users table. I've just checked the contents of the edbsrvr.ini and that has the encryption password and engine signature but no user information so unless you allow then to enter free form SQL of add a menu option to export the users file I don't see how they can get at the password.

>To go back to the bank reference, it is like me keeping my PIN secure,
>and then finding the cash is all sitting behind the tellers in big
>piles, not held in a safe. 8-)

I don't mind that. Unless they can link my PIN to the big pile of cash and its disapearing I'm OKish (interest rates wil go up to pay for their carelessness). However, just to make the analogy a bit sillier - don't forget some crooks yoicked the ATM out of the wall and drove off with it

You've obviously researched this so maybe you can answer something that baffles me. RBS use a triple "password" system - first is customer number, then three from a four character pin then 3 from a longer password (can't remember the maximum size). Every so often I try and figure out how they do that without having the pin and password in a decrypted for to check against. And fail. Do you have any idea?

Roy

Roy Lambert wrote:

> Matthew
>
>
> >> To create a new user, or maintain a users password, which is what
> >> this was required for requires the password to be in the clear at
> the >> point the user is created or the password modified. Whatever
> you do >> that is inescapable unless Tim changes how ElevateDB works.
> You are >> therefore guaranteed to have something sitting on disk, at
> multiple >> locations, to decrypt the password however stored.
> >
> > Sorry, but this is wrong.
>
> You may disagree with the approach but its factually correct (or at
> least until I'm corrected by Tim I believe it is)

Okay, to be clear, yes, the password is needed for creating and
maintaining a user's password. But it can be stored as a hash
immediately. The wrong part is that it is ever stored.



> I don't disagree for anything requiring a high level of security. I
> do agree with you - most of the password dumps I've read about come
> from SQL injection.


And the key is, EDB doesn't know how much security any customer needs,
so should assume the best practice is needed. You don't care how it is
done, and it makes no difference to the interface.


> I think I'm confused now. Only allowing users restricted access
> prevents them from exporting the users table. I've just checked the
> contents of the edbsrvr.ini and that has the encryption password and
> engine signature but no user information so unless you allow then to
> enter free form SQL of add a menu option to export the users file I
> don't see how they can get at the password.

The key here is weakness. As with most security implementations, the
design is usually good, and the implementation is where the problems
occur. Things like the SSL loopholes, where you could work things out.
EDB source is "freely available" to anyone who cares. The signatures
are there on the disk in your application, so I can decrypt the data
and work it all out. This is not about legitimate users getting access,
it is about illegitimate users. And indeed, someone who can see those
transfer files, and see the plain text passwords going by. They are
immediately usable. A salt and hash are much harder to use.

To be clear, I have seen far far worse than this. EDB is fantastic
compared to some things. I'd just like to see this moved to best
practice.


> > To go back to the bank reference, it is like me keeping my PIN
> > secure, and then finding the cash is all sitting behind the tellers
> > in big piles, not held in a safe. 8-)
>
> I don't mind that. Unless they can link my PIN to the big pile of
> cash and its disapearing I'm OKish (interest rates wil go up to pay
> for their carelessness). However, just to make the analogy a bit
> sillier - don't forget some crooks yoicked the ATM out of the wall
> and drove off with it

Yep, you are right. But as a developer, I don't want to be the one
having to explain my choice. If someone hacks the system and works out
hash matches, at least I was using tools using the best practice.

And for completeness, I checked the PCI requirements. They just require
all passwords to be encrypted in transit and storage. Which EDB does,
so long as you don't do this export for transfer thing of course, at
which point PCI fail.


>
> You've obviously researched this so maybe you can answer something
> that baffles me. RBS use a triple "password" system - first is
> customer number, then three from a four character pin then 3 from a
> longer password (can't remember the maximum size). Every so often I
> try and figure out how they do that without having the pin and
> password in a decrypted for to check against. And fail. Do you have
> any idea?

I participated in a big discussion on this once. I can work out many
ways to implement it in a proper clean modern way (for example, you
take the memorable word, make 20 combinations of the letters, hash each
one, then pick one of the combinations at check time), but mainly they
have separate hardware in secure locations to store them. They have the
money to "do it properly" with people in charge of the interfaces to
particular data and thus you can't get the data from outside, only
check against it. Most organisations don't have such control complexity
as an option.


--

Matthew Jones

Matthew

>And the key is, EDB doesn't know how much security any customer needs,
>so should assume the best practice is needed. You don't care how it is
>done, and it makes no difference to the interface.

It would be a good change but I wonder what the impact on current users would be if Tim made that sort of change?

>The signatures
>are there on the disk in your application

Yes and no - the encryption key is in there but obfusticated in a nice difficult to find way, the engine signature isn't. As long as I stick to file/server the combination of engine signature/table encryption/user passwords/ no direct user SQL input makes it fairly secure. Once moved to client/server and the standard ini file which holds the engine signature/table encryption key it isn't.

>And indeed, someone who can see those
>transfer files, and see the plain text passwords going by. They are
>immediately usable. A salt and hash are much harder to use.

That was my concern with transmitting them around in the clear.

>To be clear, I have seen far far worse than this. EDB is fantastic
>compared to some things.

You should see some of my early stuff to to make it look even better!

>make 20 combinations of the letters, hash each
>one, then pick one of the combinations at check time),

I hadn't thought of making limited sets - I always thought in terms or random(length(password)) Your approach would make it sane.

Roy Lambert