Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14307 > unrolled thread

getting started with encryption

Back to article view | Back to comp.lang.php

Contents

  getting started with encryption bill <william@TechServSys.com> - 2014-10-10 14:46 -0400
    Re: getting started with encryption Matthew Carter <m@ahungry.com> - 2014-10-10 16:36 -0400
    Re: getting started with encryption John-Paul Stewart <jpstewart@sympatico.ca> - 2014-10-10 18:53 -0400
    Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-11 09:07 +0200
      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-11 07:59 -0400
    Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-11 10:36 -0400
      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-11 10:42 -0400
        Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-11 11:45 -0400
        Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-11 18:38 +0200
          Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-11 15:16 -0400
            Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-12 10:53 +0200
              Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-12 08:17 -0400
                Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-12 08:47 -0400
                  Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-12 11:04 -0400
                    Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-12 11:13 -0400
                    Re: getting started with encryption "J. Clarke" <jclarkeusenet@cox.net> - 2014-10-12 15:12 -0400
                      Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-12 21:45 -0400
                Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-12 15:53 +0200
                  Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-12 10:07 -0400
                    How - off topic bill <william@TechServSys.com> - 2014-10-12 11:05 -0400
                      Re: How - off topic "J.O. Aho" <user@example.net> - 2014-10-12 17:27 +0200
                      Re: How - off topic Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-12 17:23 +0000
                        Re: How - off topic Tim Streater <timstreater@greenbee.net> - 2014-10-12 18:49 +0100
                      Re: How - off topic bill <william@TechServSys.com> - 2014-10-13 09:24 -0400
                  Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-12 11:01 -0400
                    Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-12 11:19 -0400
                      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-13 08:38 -0400
                        Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-13 09:18 -0400
                          Re: getting started with encryption - now off topic with gratuitous insults bill <william@TechServSys.com> - 2014-10-13 10:36 -0400
                            Re: getting started with encryption - now off topic with gratuitous insults Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-13 12:14 -0400
          Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-12 08:15 -0400
            Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-12 15:52 +0200
              Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-12 11:17 -0400
                Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-12 17:45 +0200
                  Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-13 08:58 -0400
                    Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-13 09:23 -0400
                      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-13 10:44 -0400
                        Re: getting started with encryption Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-13 12:20 -0400
                    Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-15 21:52 +0200
                    Re: getting started with encryption gordonb.1o7q6@burditt.org (Gordon Burditt) - 2014-10-16 12:13 -0500
                      Re: getting started with encryption Matthew Carter <m@ahungry.com> - 2014-10-16 15:25 -0400
                        Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-18 08:13 -0400
                      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-18 07:52 -0400
                        Re: getting started with encryption "J.O. Aho" <user@example.net> - 2014-10-18 14:46 +0200
                          Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-19 07:47 -0400
    Re: getting started with encryption Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-12 17:30 +0000
      Re: getting started with encryption bill <william@TechServSys.com> - 2014-10-13 08:59 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14335 — Re: How - off topic

On 12/10/14 17:05, bill wrote:
> On 10/12/2014 10:07 AM, Jerry Stuckle wrote:
>> On 10/12/2014 9:53 AM, J.O. Aho wrote:
>>> On 12/10/14 14:17, bill wrote:
>>>>
>>>>>
>>>>> I just pity his customer, who will suffer quite a lot of this and
>>>>> it seems they have not got the best service, a lot of   to
>>>>> place elements, meta refresh to redirect to the new wordpress
>>>>> page (looks cheap when you get to see the old page before the
>>>>> wordpress page loads, which seems to have some misconfiguration).
>>>>>
>>>>>
>>>> Before you jump all over me you should know:
>>>>       I didn't code nor do I maintain the public website.  That was
>>>> coded
>>>> by one of the docs who loves WordPress.
>>>
>>> Your own homepage written by one of your customers?
>>>
>>
>> I hadn't looked at his home page before you mentioned it.  But now I see
>> what you mean.
>>
>
> as a matter of interest: How did you guys get from my email address to
> the public website?  I know how to get from domain to registrant but not
> the other way.

Many times, the mail domain and the web domain are the same, for example 
(as we are just make examples, we use example.net/org/com as those are 
dedicated to be used for just examples) we have someones email address:

person.name@example.net

remove everything before and including '@'.

Then just visiting http://example.net will lead you to the web site 
which is associated with the mail domain. Of course this will not work 
for all mail addresses, as most people with an gmail address will not 
have anything else to do with gmail than being customers.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14337 — Re: How - off topic

On Sun, 12 Oct 2014 11:05:50 -0400, bill wrote:

> as a matter of interest: How did you guys get from my email address to
> the public website?

You're designing "secure" systems that connect to the internet, and you 
haven't realised that an email of the form name@somedomain.sometld might 
just infer the presence of a website at somedomain.sometld or maybe 
www.somedomain.sometld ?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14339 — Re: How - off topic

In article <m1edeu$qr1$1@dont-email.me>, Denis McMahon
<denismfmcmahon@gmail.com> wrote:

> You're designing "secure" systems that connect to the internet, and you 
> haven't realised that an email of the form name@somedomain.sometld might 
> just infer the presence of a website at somedomain.sometld or maybe ...

"imply", not "infer".

-- 
"If you're not able to ask questions and deal with the answers without feeling 
that someone has called your intelligence or competence into question, don't 
ask questions on Usenet where the answers won't be carefully tailored to avoid
tripping your hair-trigger insecurities."                  - D M Procida, UCSM

[toc] | [prev] | [next] | [standalone]

#14347 — Re: How - off topic

On 10/12/2014 11:05 AM, bill wrote:
> On 10/12/2014 10:07 AM, Jerry Stuckle wrote:
>> On 10/12/2014 9:53 AM, J.O. Aho wrote:
>>> On 12/10/14 14:17, bill wrote:
>>>>
>>>>>
>>>>> I just pity his customer, who will suffer quite a lot of
>>>>> this and
>>>>> it seems they have not got the best service, a lot of   to
>>>>> place elements, meta refresh to redirect to the new wordpress
>>>>> page (looks cheap when you get to see the old page before the
>>>>> wordpress page loads, which seems to have some
>>>>> misconfiguration).
>>>>>
>>>>>
>>>> Before you jump all over me you should know:
>>>>       I didn't code nor do I maintain the public website.
>>>> That was coded
>>>> by one of the docs who loves WordPress.
>>>
>>> Your own homepage written by one of your customers?
>>>
>>
>> I hadn't looked at his home page before you mentioned it.  But
>> now I see
>> what you mean.
>>
>
> as a matter of interest: How did you guys get from my email
> address to the public website?  I know how to get from domain to
> registrant but not the other way.
>
> -bill

I forgot about that link.  Over a period of time TSS began doing 
more and more work for Michigan Psychotherapy and when they 
planned a major EMR update for 2000 it made more sense for them 
to just buy TSS.  The price was right.  TSS is a domain that I 
just use for email now.  I went from entrepreneur to corporate 
drone.

bill

[toc] | [prev] | [next] | [standalone]

#14329

On 10/12/2014 9:53 AM, J.O. Aho wrote:
> On 12/10/14 14:17, bill wrote:
>>
>>>
>>> I just pity his customer, who will suffer quite a lot of this and
>>> it seems they have not got the best service, a lot of   to
>>> place elements, meta refresh to redirect to the new wordpress
>>> page (looks cheap when you get to see the old page before the
>>> wordpress page loads, which seems to have some misconfiguration).
>>>
>>>
>> Before you jump all over me you should know:
>>      I didn't code nor do I maintain the public website.  That
>> was coded
>> by one of the docs who loves WordPress.
>
> Your own homepage written by one of your customers?

No, the "doc" and I both work for the company.
Guess who has more status.
Guess who doesn't get listened to on a regular basis.

-bill

[toc] | [prev] | [next] | [standalone]

#14334

On 10/12/2014 11:01 AM, bill wrote:
> On 10/12/2014 9:53 AM, J.O. Aho wrote:
>> On 12/10/14 14:17, bill wrote:
>>>
>>>>
>>>> I just pity his customer, who will suffer quite a lot of this and
>>>> it seems they have not got the best service, a lot of   to
>>>> place elements, meta refresh to redirect to the new wordpress
>>>> page (looks cheap when you get to see the old page before the
>>>> wordpress page loads, which seems to have some misconfiguration).
>>>>
>>>>
>>> Before you jump all over me you should know:
>>>      I didn't code nor do I maintain the public website.  That
>>> was coded
>>> by one of the docs who loves WordPress.
>>
>> Your own homepage written by one of your customers?
> 
> No, the "doc" and I both work for the company.
> Guess who has more status.
> Guess who doesn't get listened to on a regular basis.
> 
> -bill
> 
> 
> 

The "doc" works for Technical Service Systems?  If he has "more status",
why are you listed as both the tech and admin contacts for the web site?

I don't think so...  But I also find your Michigan Psychotherapy page is
blocked by my antivirus software.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14342

On 10/12/2014 11:19 AM, Jerry Stuckle wrote:
> On 10/12/2014 11:01 AM, bill wrote:
>> On 10/12/2014 9:53 AM, J.O. Aho wrote:
>>> On 12/10/14 14:17, bill wrote:
>>>>
>>>>>
>>>>> I just pity his customer, who will suffer quite a lot of this and
>>>>> it seems they have not got the best service, a lot of   to
>>>>> place elements, meta refresh to redirect to the new wordpress
>>>>> page (looks cheap when you get to see the old page before the
>>>>> wordpress page loads, which seems to have some misconfiguration).
>>>>>
>>>>>
>>>> Before you jump all over me you should know:
>>>>       I didn't code nor do I maintain the public website.  That
>>>> was coded
>>>> by one of the docs who loves WordPress.
>>>
>>> Your own homepage written by one of your customers?
>>
>> No, the "doc" and I both work for the company.
>> Guess who has more status.
>> Guess who doesn't get listened to on a regular basis.
>>
>> -bill
>>
>>
>>
>
> The "doc" works for Technical Service Systems?  If he has "more status",
> why are you listed as both the tech and admin contacts for the web site?

see my prior answer to J.O.
>
> I don't think so...  But I also find your Michigan Psychotherapy page is
> blocked by my antivirus software.
>
That is curious.  Does it tell you what bothers it?  I'd be glad 
to pass the info on to the doc.  Maybe he'll let me write it 
right(er).

-bill

[toc] | [prev] | [next] | [standalone]

#14345

On 10/13/2014 8:38 AM, bill wrote:
> On 10/12/2014 11:19 AM, Jerry Stuckle wrote:
>> On 10/12/2014 11:01 AM, bill wrote:
>>> On 10/12/2014 9:53 AM, J.O. Aho wrote:
>>>> On 12/10/14 14:17, bill wrote:
>>>>>
>>>>>>
>>>>>> I just pity his customer, who will suffer quite a lot of this and
>>>>>> it seems they have not got the best service, a lot of   to
>>>>>> place elements, meta refresh to redirect to the new wordpress
>>>>>> page (looks cheap when you get to see the old page before the
>>>>>> wordpress page loads, which seems to have some misconfiguration).
>>>>>>
>>>>>>
>>>>> Before you jump all over me you should know:
>>>>>       I didn't code nor do I maintain the public website.  That
>>>>> was coded
>>>>> by one of the docs who loves WordPress.
>>>>
>>>> Your own homepage written by one of your customers?
>>>
>>> No, the "doc" and I both work for the company.
>>> Guess who has more status.
>>> Guess who doesn't get listened to on a regular basis.
>>>
>>> -bill
>>>
>>>
>>>
>>
>> The "doc" works for Technical Service Systems?  If he has "more status",
>> why are you listed as both the tech and admin contacts for the web site?
> 
> see my prior answer to J.O.

I saw it.  Obviously you are clueless (on a number of things).

>>
>> I don't think so...  But I also find your Michigan Psychotherapy page is
>> blocked by my antivirus software.
>>
> That is curious.  Does it tell you what bothers it?  I'd be glad to pass
> the info on to the doc.  Maybe he'll let me write it right(er).
> 
> -bill
> 

No, and I really don't care.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14348 — Re: getting started with encryption - now off topic with gratuitous insults

>> see my prior answer to J.O.
>
> I saw it.  Obviously you are clueless (on a number of things).

Of course I am.  As are you and all the rest of humanity.
>
>>>
>>> I don't think so...  But I also find your Michigan Psychotherapy page is
>>> blocked by my antivirus software.
>>>
>> That is curious.  Does it tell you what bothers it?  I'd be glad to pass
>> the info on to the doc.  Maybe he'll let me write it right(er).
>>
>> -bill
>>
>
> No, and I really don't care.

Did you get up on the wrong side of the bed this morning?

-bill

[toc] | [prev] | [next] | [standalone]

#14350 — Re: getting started with encryption - now off topic with gratuitous insults

On 10/13/2014 10:36 AM, bill wrote:
> 
>>> see my prior answer to J.O.
>>
>> I saw it.  Obviously you are clueless (on a number of things).
> 
> Of course I am.  As are you and all the rest of humanity.
>>
>>>>
>>>> I don't think so...  But I also find your Michigan Psychotherapy
>>>> page is
>>>> blocked by my antivirus software.
>>>>
>>> That is curious.  Does it tell you what bothers it?  I'd be glad to pass
>>> the info on to the doc.  Maybe he'll let me write it right(er).
>>>
>>> -bill
>>>
>>
>> No, and I really don't care.
> 
> Did you get up on the wrong side of the bed this morning?
> 
> -bill
> 
> 

Nope.  I really don't care why the page is being blocked.  If someone
wants to create a crappy page, I'm not going to stop him.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14323

On 10/11/2014 12:38 PM, J.O. Aho wrote:
>
> Session data stored in persistent storage will give the
> unauthorized 3rd party all they may need to decrypt the database.
> A brute force attack will be a lot simpler when just need to
> figure out a string.

Would you be so kind as to expand on this theme ?

Thanks for the Cornucopia link.

-bill

[toc] | [prev] | [next] | [standalone]

#14326

On 12/10/14 14:15, bill wrote:
> On 10/11/2014 12:38 PM, J.O. Aho wrote:
>>
>> Session data stored in persistent storage will give the
>> unauthorized 3rd party all they may need to decrypt the database.
>> A brute force attack will be a lot simpler when just need to
>> figure out a string.
>
> Would you be so kind as to expand on this theme ?

Assumption based on your earlier descriptions:
- Decryption/encryption is done in the web application layer
- Password for decrypt/encrypt is valid for a 3 hour session

You need to store the session somewhere,
using the session() which is used by php it will by default store the 
session data on disk. As it's on disk, it's easy to just open the 
session file and read the password from it and the third party has full 
access to the data.

Even if you manage to delete or keep the session data out of reach for 
the 3rd party, it's simple to write a brute force script which can try 
to figure out the password trying dictionary words and random 
characters, as there will be no mechanism to prevent unlimited tries. 
[figure out a string]


Using encryption keys which are handled by the database, you have 
something that is more difficult to generate, a valid key and the 
database may lock the user which tries more than X times with the wrong key.


> Thanks for the Cornucopia link.

Np.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14333

On 10/12/2014 9:52 AM, J.O. Aho wrote:
> On 12/10/14 14:15, bill wrote:
>> On 10/11/2014 12:38 PM, J.O. Aho wrote:
>>>
>>> Session data stored in persistent storage will give the
>>> unauthorized 3rd party all they may need to decrypt the database.
>>> A brute force attack will be a lot simpler when just need to
>>> figure out a string.
>>
>> Would you be so kind as to expand on this theme ?
>
> Assumption based on your earlier descriptions:
> - Decryption/encryption is done in the web application layer
> - Password for decrypt/encrypt is valid for a 3 hour session
>
> You need to store the session somewhere,
> using the session() which is used by php it will by default store
> the session data on disk. As it's on disk, it's easy to just open
> the session file and read the password from it and the third
> party has full access to the data.
>
> Even if you manage to delete or keep the session data out of
> reach for the 3rd party, it's simple to write a brute force
> script which can try to figure out the password trying dictionary
> words and random characters, as there will be no mechanism to
> prevent unlimited tries. [figure out a string]
>
>
> Using encryption keys which are handled by the database, you have
> something that is more difficult to generate, a valid key and the
> database may lock the user which tries more than X times with the
> wrong key.

I understand that.  Changing databases in a reasonably short 
amount of time would be a problem.  I didn't use a database 
abstraction layer so that would be a major rewrite.  Maybe for 
the next version (due in 2020).

Although it seems paradoxical, would keeping the key in a cookie 
on the client machine be more secure? (assuming the cookie is 
overwritten at timeout or logoff) It would involve a lot of 
transmitting the key to the server, but this is over a physically 
secure LAN or hardware VPN.  The thought of that makes me 
shudder, but.....
It would address the issue of physical theft of the server.

-bill

[toc] | [prev] | [next] | [standalone]

#14336

On 12/10/14 17:17, bill wrote:
> On 10/12/2014 9:52 AM, J.O. Aho wrote:
>> On 12/10/14 14:15, bill wrote:
>>> On 10/11/2014 12:38 PM, J.O. Aho wrote:
>>>>
>>>> Session data stored in persistent storage will give the
>>>> unauthorized 3rd party all they may need to decrypt the database.
>>>> A brute force attack will be a lot simpler when just need to
>>>> figure out a string.
>>>
>>> Would you be so kind as to expand on this theme ?
>>
>> Assumption based on your earlier descriptions:
>> - Decryption/encryption is done in the web application layer
>> - Password for decrypt/encrypt is valid for a 3 hour session
>>
>> You need to store the session somewhere,
>> using the session() which is used by php it will by default store
>> the session data on disk. As it's on disk, it's easy to just open
>> the session file and read the password from it and the third
>> party has full access to the data.
>>
>> Even if you manage to delete or keep the session data out of
>> reach for the 3rd party, it's simple to write a brute force
>> script which can try to figure out the password trying dictionary
>> words and random characters, as there will be no mechanism to
>> prevent unlimited tries. [figure out a string]
>>
>>
>> Using encryption keys which are handled by the database, you have
>> something that is more difficult to generate, a valid key and the
>> database may lock the user which tries more than X times with the
>> wrong key.
>
> I understand that.  Changing databases in a reasonably short amount of
> time would be a problem.  I didn't use a database abstraction layer so
> that would be a major rewrite.  Maybe for the next version (due in 2020).

Waiting that long to fix a shortcoming is a bit long, even if it take 
some time for you to rewrite the database section of your project, it 
will be worth it and can make it easier to expand at a later stage with 
new functionality.

I would strongly suggest postgresql as a replacement for mysql, as it 
does support encryption with pgp keys, sure I don't expect that 
switching database will go without issues, it hardly does.

http://www.postgresql.org/docs/9.3/static/pgcrypto.html

Sure, if you have money, go with InterSystems database, but they will 
charge by how many users will use the system. We did look at it as a 
replacement for Sybase, but the cost for us would have been too high, 
but had served our PCI DSS requirements.


> Although it seems paradoxical, would keeping the key in a cookie on the
> client machine be more secure?

No, for then it's up to grabs for anyone who can access the client 
machine, anything on the client side should ALWAYS be considered as 
insecure and untrustworthy.


> (assuming the cookie is overwritten at
> timeout or logoff) It would involve a lot of transmitting the key to the
> server, but this is over a physically secure LAN or hardware VPN.

Don't matter, it's still insecure and untrustworthy, even if you use SSL 
on the intranet web server, but I do recommend usage of SSL even in an 
internal network, as not only outsiders may be keen on mischief, many 
times you have someone internally who is the bad guy or assisting 
someone outside.


IMHO there is no good way to solve it than using database level 
encryption of the data.


> The thought of that makes me shudder, but.....
> It would address the issue of physical theft of the server.

Yes, but that you need to address too, regarding something for it feels 
too unlikely, will become your Achilles heel.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14343

On 10/12/2014 11:45 AM, J.O. Aho wrote:

...

   Maybe for the next version (due
>> in 2020).
>
> Waiting that long to fix a shortcoming is a bit long, even if it
> take some time for you to rewrite the database section of your
> project, it will be worth it and can make it easier to expand at
> a later stage with new functionality.
>
I do agree.  I'll make the pitch.

> I would strongly suggest postgresql as a replacement for mysql,
> as it does support encryption with pgp keys, sure I don't expect
> that switching database will go without issues, it hardly does.
>
> http://www.postgresql.org/docs/9.3/static/pgcrypto.html

Thanks

>
>> Although it seems paradoxical, would keeping the key in a
>> cookie on the
>> client machine be more secure?
>
> No, for then it's up to grabs for anyone who can access the
> client machine, anything on the client side should ALWAYS be
> considered as insecure and untrustworthy.
>
>
>> (assuming the cookie is overwritten at
>> timeout or logoff) It would involve a lot of transmitting the
>> key to the
>> server, but this is over a physically secure LAN or hardware VPN.
>
> Don't matter, it's still insecure and untrustworthy, even if you
> use SSL on the intranet web server, but I do recommend usage of
> SSL even in an internal network, as not only outsiders may be
> keen on mischief, many times you have someone internally who is
> the bad guy or assisting someone outside.

In this case, the only inside people are the ones with access 
privileges already
>
>
> IMHO there is no good way to solve it than using database level
> encryption of the data.
>
>
>> The thought of that makes me shudder, but.....
>> It would address the issue of physical theft of the server.
>
> Yes, but that you need to address too, regarding something for it
> feels too unlikely, will become your Achilles heel.
>
>
What do you think of this:

At logon, after the user's credentials are verified, the office 
server will (over https)
send a token request to a remote server
take the returned token, modify it to use as transaction token
using the transaction token, request the encryption key (the 
remote server will verify that the modified transaction token is 
correct)

The key is then kept in a mySQL MEMORY engine table and
the table is DROPed at logout

This would protect against server theft - unless they steal the 
UPS too.  No one but the superuser knows the key. (of course the 
key needs to be kept in a secure place... just in case)

-bill

[toc] | [prev] | [next] | [standalone]

#14346

On 10/13/2014 8:58 AM, bill wrote:
> On 10/12/2014 11:45 AM, J.O. Aho wrote:
> 
> ...
> 
>   Maybe for the next version (due
>>> in 2020).
>>
>> Waiting that long to fix a shortcoming is a bit long, even if it
>> take some time for you to rewrite the database section of your
>> project, it will be worth it and can make it easier to expand at
>> a later stage with new functionality.
>>
> I do agree.  I'll make the pitch.
> 
>> I would strongly suggest postgresql as a replacement for mysql,
>> as it does support encryption with pgp keys, sure I don't expect
>> that switching database will go without issues, it hardly does.
>>
>> http://www.postgresql.org/docs/9.3/static/pgcrypto.html
> 
> Thanks
> 
>>
>>> Although it seems paradoxical, would keeping the key in a
>>> cookie on the
>>> client machine be more secure?
>>
>> No, for then it's up to grabs for anyone who can access the
>> client machine, anything on the client side should ALWAYS be
>> considered as insecure and untrustworthy.
>>
>>
>>> (assuming the cookie is overwritten at
>>> timeout or logoff) It would involve a lot of transmitting the
>>> key to the
>>> server, but this is over a physically secure LAN or hardware VPN.
>>
>> Don't matter, it's still insecure and untrustworthy, even if you
>> use SSL on the intranet web server, but I do recommend usage of
>> SSL even in an internal network, as not only outsiders may be
>> keen on mischief, many times you have someone internally who is
>> the bad guy or assisting someone outside.
> 
> In this case, the only inside people are the ones with access privileges
> already

Over 80% of data breeches are because of "someone inside" - either
through carelessness or intentional damage.

>>
>>
>> IMHO there is no good way to solve it than using database level
>> encryption of the data.
>>
>>
>>> The thought of that makes me shudder, but.....
>>> It would address the issue of physical theft of the server.
>>
>> Yes, but that you need to address too, regarding something for it
>> feels too unlikely, will become your Achilles heel.
>>
>>
> What do you think of this:
> 
> At logon, after the user's credentials are verified, the office server
> will (over https)
> send a token request to a remote server
> take the returned token, modify it to use as transaction token
> using the transaction token, request the encryption key (the remote
> server will verify that the modified transaction token is correct)
> 
> The key is then kept in a mySQL MEMORY engine table and
> the table is DROPed at logout
> 
> This would protect against server theft - unless they steal the UPS
> too.  No one but the superuser knows the key. (of course the key needs
> to be kept in a secure place... just in case)
> 
> -bill
> 

I hope you like a few years of free room and board courtesy of the Feds
(or at the very least paying a six or seven figure fine).  HIPAA is NOT
something to fool with.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14349

On 10/13/2014 9:23 AM, Jerry Stuckle wrote:
...
>>>
>> What do you think of this:
>>
>> At logon, after the user's credentials are verified, the office server
>> will (over https)
>> send a token request to a remote server
>> take the returned token, modify it to use as transaction token
>> using the transaction token, request the encryption key (the remote
>> server will verify that the modified transaction token is correct)
>>
>> The key is then kept in a mySQL MEMORY engine table and
>> the table is DROPed at logout
>>
>> This would protect against server theft - unless they steal the UPS
>> too.  No one but the superuser knows the key. (of course the key needs
>> to be kept in a secure place... just in case)
>>
>> -bill
>>
>
> I hope you like a few years of free room and board courtesy of the Feds
> (or at the very least paying a six or seven figure fine).  HIPAA is NOT
> something to fool with.
>
A) HIPAA is not a criminal statute.
B) HIPAA auditors look well upon attention paid to blocking 
intrusions (physical or electronic) even when they have failed.
C) for physical security, a knob in door lock is adequate 
protection for physical files (within a secure building). We know 
how insecure that is)
D) HIPAA auditors routinely give practices a 2nd chance after an 
inspection that fails on the condition that the practice fix the 
problems identified.

I appreciate your attempts to save the practice a big fine, but I 
suggest that as HIPAA compliance is 50% of my job (for which I 
have been trained), I probably know a bit more about it than you do.

Now, would you like to look at the suggestion above with a 
critical eye?

-bill

[toc] | [prev] | [next] | [standalone]

#14351

On 10/13/2014 10:44 AM, bill wrote:
> On 10/13/2014 9:23 AM, Jerry Stuckle wrote:
> ...
>>>>
>>> What do you think of this:
>>>
>>> At logon, after the user's credentials are verified, the office server
>>> will (over https)
>>> send a token request to a remote server
>>> take the returned token, modify it to use as transaction token
>>> using the transaction token, request the encryption key (the remote
>>> server will verify that the modified transaction token is correct)
>>>
>>> The key is then kept in a mySQL MEMORY engine table and
>>> the table is DROPed at logout
>>>
>>> This would protect against server theft - unless they steal the UPS
>>> too.  No one but the superuser knows the key. (of course the key needs
>>> to be kept in a secure place... just in case)
>>>
>>> -bill
>>>
>>
>> I hope you like a few years of free room and board courtesy of the Feds
>> (or at the very least paying a six or seven figure fine).  HIPAA is NOT
>> something to fool with.
>>
> A) HIPAA is not a criminal statute.
> B) HIPAA auditors look well upon attention paid to blocking intrusions
> (physical or electronic) even when they have failed.
> C) for physical security, a knob in door lock is adequate protection for
> physical files (within a secure building). We know how insecure that is)
> D) HIPAA auditors routinely give practices a 2nd chance after an
> inspection that fails on the condition that the practice fix the
> problems identified.
> 
> I appreciate your attempts to save the practice a big fine, but I
> suggest that as HIPAA compliance is 50% of my job (for which I have been
> trained), I probably know a bit more about it than you do.
> 
> Now, would you like to look at the suggestion above with a critical eye?
> 
> -bill

It all depends on how effective the security precautions were and the
extent of the exposure.  A half-arsed attempt will quickly net a big
fine on the first time.  I know of at least one doctors office which was
using WiFi with WEP encryption.  Now WEP is a known weak encryption, and
not suitable for patients' records.  The Feds assessed a big fine when
they discovered it.  No warning.

And they are clamping down even more with the new Affordable Health Care
(ObamaCare) law.

And no, you do NOT know more about it than I do.  Otherwise you would
not be proposing the solution and asking the questions you are.

You've already been given good advice, yet you make excuses as to why
you won't implement proper security.  So no, I will not waste my time
trying to save your arse any longer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14356

On 13/10/14 14:58, bill wrote:

> What do you think of this:
>
> At logon, after the user's credentials are verified, the office server
> will (over https)
> send a token request to a remote server
> take the returned token, modify it to use as transaction token
> using the transaction token, request the encryption key (the remote
> server will verify that the modified transaction token is correct)
>
> The key is then kept in a mySQL MEMORY engine table and
> the table is DROPed at logout
>
> This would protect against server theft - unless they steal the UPS
> too.  No one but the superuser knows the key. (of course the key needs
> to be kept in a secure place... just in case)

Take a look at tokenizor, you save the token in the mysql server, and 
the data on the tokenizor, so each time you need to get to the encrypted 
data, you need to ask the tokenizor to give you the data with presenting 
the right token, of course you need to validate that the user in 
question has the right to use the tokenizor.

Sure, you will be able to make a lot of things wrong in this process, 
which makes this to not work as securely as you think. There are of 
course commercial products you could use for this, but they tend to cost.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14359

>> Don't matter, it's still insecure and untrustworthy, even if you
>> use SSL on the intranet web server, but I do recommend usage of
>> SSL even in an internal network, as not only outsiders may be
>> keen on mischief, many times you have someone internally who is
>> the bad guy or assisting someone outside.
> 
> In this case, the only inside people are the ones with access 
> privileges already

Really?  Does that include the janitor?  The guy who sprays for
termites and roaches?  Patients?  Children of employees?  Burglars?

> The key is then kept in a mySQL MEMORY engine table and
> the table is DROPed at logout
> 
> This would protect against server theft - unless they steal the 
> UPS too.  No one but the superuser knows the key. (of course the 
> key needs to be kept in a secure place... just in case)

You *DO* have encrypted swap, don't you?  Otherwise you don't have
protection for the key in a MEMORY table.

There are also supposed to be some techniques for freezing the
memory to lengthen the retention time to hours after power-off, but
there are likely only a few people who can do that well.

The regulations for medical information are complicated enough that
even if the information *IS* safe, you can still get in trouble for
not being able to *PROVE* it's safe.  You're taking risks similar
to having unprotected sex with an Ebola patient.  Even if you survive
the disease, you're likely to have everything in your house burned.
You probably need a lawyer as a project leader for this project.
And don't let programmers not certified in handling medical information
work on the code, or even read it.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web