"Andy" <ajj3***@alum.rit.edu> wrote in message
news:1143573820.754223.139480@u72g2000cwu.googlegroups.com...
> It sounds like it would still be possible for an attacker to put junk
> data into your system.  Take your encrypted value, and replace it with
> another encrypted value.  SSL would prevent this kind of tampering,
> since the whole message is signed, not just individual fields.
>
> Leaving port 1433 open to the internet has caused problems in the past;
> perhaps you heard of the slammer worm?
>
> Even with a strongly named assembly you are still open to some kinds of
> attacks.
>
> Finally you may need to communicate data with a web service at some
> point, and I doubt you'd want to provide your key to the 3rd party.
>

"Rob R. Ainscough" <roba***@pacbell.net> wrote in message
news:Oqt$gTrUGHA.5808@TK2MSFTNGP12.phx.gbl...
> How would they put junk data into my system?  Are you assuming they've
> been able to hack in via an account?  Unless ADO.NET 2.0 has some
> fundamental security flaws when communicating to a SQL server?  I could
> encrypt the entire message also, all that SSL does for me is provide
> encrypted access to external sources beyond the control of my security.
>
> Slammer real world impact has been relatively low threat (which has been
> countered via a patch a long time ago) -- in fact, it will provide zero
> benefit in my situation (even if the SQL server is not patched) -- gaining
> Windows Service security context (sends 376 bytes to UDP port 1434 for
> buffer overflow) means nothing to the way my security is established -- 
> the only way they can obtain any value is if they were able to locate my
> strong name DLL responsible for all security aspects, assuming they could
> get into the DLL and somehow decompile it (without the public/private key
> pair) they would then have to discover where in the DLL the call is to get
> the encrypted key and then also have to realize that key needs to be
> unencrypted.
>
> In fact, the way my security is enforced has minimal reliance on the OS or
> the SQL server -- about all a hacker could do is delete or change data and
> that is assuming they have found a flaw in the OS/Service (i.e.
> lammer)  --  data changes will soon be rejected by my applications as they
> will not validate and be rejected as bogus data.
>
> Can you provide details of how you might attack a strongly named assembly?
> Opening the file in binary will not be terribly helpful and you can't
> decompile it to any useful context, so please explain?
>
> Web Services use the same approach, none of my web service will do
> anything if they don't get a valid encrypted key as a parameter to all and
> any method made available by the service and any sensitive data passed to
> from a web service is always encrypted.
>
> Rob
>
> "Andy" <ajj3***@alum.rit.edu> wrote in message
> news:1143573820.754223.139480@u72g2000cwu.googlegroups.com...
>> It sounds like it would still be possible for an attacker to put junk
>> data into your system.  Take your encrypted value, and replace it with
>> another encrypted value.  SSL would prevent this kind of tampering,
>> since the whole message is signed, not just individual fields.
>>
>> Leaving port 1433 open to the internet has caused problems in the past;
>> perhaps you heard of the slammer worm?
>>
>> Even with a strongly named assembly you are still open to some kinds of
>> attacks.
>>
>> Finally you may need to communicate data with a web service at some
>> point, and I doubt you'd want to provide your key to the 3rd party.
>>
>
>

"Henning Krause [MVP]" <newsgroups.rem***@this.infinitec.de> wrote in
message news:erwXGkrUGHA.5500@TK2MSFTNGP12.phx.gbl...
> Hello Rob,
>
> If an attacker compromises your system somehow and gets your strong named
> assembly, he can simply decompile it. A strong name doesn't protect an
> assembly from being decompiled at all.
>
> You talk about passwords with a length of 40 characters - how are they
> used? Are those passwords stored somewhere? (Surely they will - there are
> very few people who will remember a 40 char password which meets some
> complexity requirements). How are they transferred over the wire?
>
> You say that you are transmitting all sensitive data in an encrypted
> form - what encryption do you use? Symetric? Asymetric? If you are using
> the first, you must exchange the keys securely - and store them securely.
> If you are using asymetric encryption, you are rebuilding https...
>
> Talking about Slammer... yes there might be a patch - but you don't know
> for sure if there is another, yet undiscovered hole. Undiscovered by the
> public...  And if the attacker gains access to the SQL Server, he *might*
> be able to get access to your strong named assembly. And after he
> decompiled the assembly he will find the secret encryption key.
>
> The encryption key itself - are you using one for all the encryption
> stuff? How often do you change it? It looks to me like a single point of
> failure.
>
> Regards,
> Henning Krause
>
> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message
> news:Oqt$gTrUGHA.5808@TK2MSFTNGP12.phx.gbl...
>> How would they put junk data into my system?  Are you assuming they've
>> been able to hack in via an account?  Unless ADO.NET 2.0 has some
>> fundamental security flaws when communicating to a SQL server?  I could
>> encrypt the entire message also, all that SSL does for me is provide
>> encrypted access to external sources beyond the control of my security.
>>
>> Slammer real world impact has been relatively low threat (which has been
>> countered via a patch a long time ago) -- in fact, it will provide zero
>> benefit in my situation (even if the SQL server is not patched) -- 
>> gaining Windows Service security context (sends 376 bytes to UDP port
>> 1434 for buffer overflow) means nothing to the way my security is
>> established --  the only way they can obtain any value is if they were
>> able to locate my strong name DLL responsible for all security aspects,
>> assuming they could get into the DLL and somehow decompile it (without
>> the public/private key pair) they would then have to discover where in
>> the DLL the call is to get the encrypted key and then also have to
>> realize that key needs to be unencrypted.
>>
>> In fact, the way my security is enforced has minimal reliance on the OS
>> or the SQL server -- about all a hacker could do is delete or change data
>> and that is assuming they have found a flaw in the OS/Service (i.e.
>> lammer)  --  data changes will soon be rejected by my applications as
>> they will not validate and be rejected as bogus data.
>>
>> Can you provide details of how you might attack a strongly named
>> assembly? Opening the file in binary will not be terribly helpful and you
>> can't decompile it to any useful context, so please explain?
>>
>> Web Services use the same approach, none of my web service will do
>> anything if they don't get a valid encrypted key as a parameter to all
>> and any method made available by the service and any sensitive data
>> passed to from a web service is always encrypted.
>>
>> Rob
>>
>> "Andy" <ajj3***@alum.rit.edu> wrote in message
>> news:1143573820.754223.139480@u72g2000cwu.googlegroups.com...
>>> It sounds like it would still be possible for an attacker to put junk
>>> data into your system.  Take your encrypted value, and replace it with
>>> another encrypted value.  SSL would prevent this kind of tampering,
>>> since the whole message is signed, not just individual fields.
>>>
>>> Leaving port 1433 open to the internet has caused problems in the past;
>>> perhaps you heard of the slammer worm?
>>>
>>> Even with a strongly named assembly you are still open to some kinds of
>>> attacks.
>>>
>>> Finally you may need to communicate data with a web service at some
>>> point, and I doubt you'd want to provide your key to the 3rd party.
>>>
>>
>>
>
>

"Rob R. Ainscough" <roba***@pacbell.net> wrote in message
news:ey4URHsUGHA.1444@TK2MSFTNGP11.phx.gbl...
> The Key is not contained in the assembly -- can't give you more details
> than that.  But you appear to be correct, the strong name assembly can be
> decompiled (I just did it).
>
> Henning there are a lot of things I don't know for sure and hence why I've
> implemented my own security.  There are a lot of things I don't know for
> sure about SSL or just about any technology that has been created by
> someone else.  Slammer is a classic example and I agree with you, that's
> why I do NOT want to rely on someone else's "secure" implementations.  The
> vulnerabilities of these are just as unknown as the security approach I'm
> using to ensure a hacker moves on to a more easy target like sa
> "password".
>
> And then there is TCP/IP, talk about weak on security.
>
> I prefer my approach, because that requires a hacker to have knowledge of
> how my application works even with a decompile that could take them a long
> time and they'd be trying to understand a moving target and the updates
> come fast and furious -- assuming of course they discovered the correct
> DLL amoung thousands of DLL on a server.
>
> "Henning Krause [MVP]" <newsgroups.rem***@this.infinitec.de> wrote in
> message news:erwXGkrUGHA.5500@TK2MSFTNGP12.phx.gbl...
>> Hello Rob,
>>
>> If an attacker compromises your system somehow and gets your strong named
>> assembly, he can simply decompile it. A strong name doesn't protect an
>> assembly from being decompiled at all.
>>
>> You talk about passwords with a length of 40 characters - how are they
>> used? Are those passwords stored somewhere? (Surely they will - there are
>> very few people who will remember a 40 char password which meets some
>> complexity requirements). How are they transferred over the wire?
>>
>> You say that you are transmitting all sensitive data in an encrypted
>> form - what encryption do you use? Symetric? Asymetric? If you are using
>> the first, you must exchange the keys securely - and store them securely.
>> If you are using asymetric encryption, you are rebuilding https...
>>
>> Talking about Slammer... yes there might be a patch - but you don't know
>> for sure if there is another, yet undiscovered hole. Undiscovered by the
>> public...  And if the attacker gains access to the SQL Server, he *might*
>> be able to get access to your strong named assembly. And after he
>> decompiled the assembly he will find the secret encryption key.
>>
>> The encryption key itself - are you using one for all the encryption
>> stuff? How often do you change it? It looks to me like a single point of
>> failure.
>>
>> Regards,
>> Henning Krause
>>
>> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message
>> news:Oqt$gTrUGHA.5808@TK2MSFTNGP12.phx.gbl...
>>> How would they put junk data into my system?  Are you assuming they've
>>> been able to hack in via an account?  Unless ADO.NET 2.0 has some
>>> fundamental security flaws when communicating to a SQL server?  I could
>>> encrypt the entire message also, all that SSL does for me is provide
>>> encrypted access to external sources beyond the control of my security.
>>>
>>> Slammer real world impact has been relatively low threat (which has been
>>> countered via a patch a long time ago) -- in fact, it will provide zero
>>> benefit in my situation (even if the SQL server is not patched) -- 
>>> gaining Windows Service security context (sends 376 bytes to UDP port
>>> 1434 for buffer overflow) means nothing to the way my security is
>>> established --  the only way they can obtain any value is if they were
>>> able to locate my strong name DLL responsible for all security aspects,
>>> assuming they could get into the DLL and somehow decompile it (without
>>> the public/private key pair) they would then have to discover where in
>>> the DLL the call is to get the encrypted key and then also have to
>>> realize that key needs to be unencrypted.
>>>
>>> In fact, the way my security is enforced has minimal reliance on the OS
>>> or the SQL server -- about all a hacker could do is delete or change
>>> data and that is assuming they have found a flaw in the OS/Service (i.e.
>>> lammer)  --  data changes will soon be rejected by my applications as
>>> they will not validate and be rejected as bogus data.
>>>
>>> Can you provide details of how you might attack a strongly named
>>> assembly? Opening the file in binary will not be terribly helpful and
>>> you can't decompile it to any useful context, so please explain?
>>>
>>> Web Services use the same approach, none of my web service will do
>>> anything if they don't get a valid encrypted key as a parameter to all
>>> and any method made available by the service and any sensitive data
>>> passed to from a web service is always encrypted.
>>>
>>> Rob
>>>
>>> "Andy" <ajj3***@alum.rit.edu> wrote in message
>>> news:1143573820.754223.139480@u72g2000cwu.googlegroups.com...
>>>> It sounds like it would still be possible for an attacker to put junk
>>>> data into your system.  Take your encrypted value, and replace it with
>>>> another encrypted value.  SSL would prevent this kind of tampering,
>>>> since the whole message is signed, not just individual fields.
>>>>
>>>> Leaving port 1433 open to the internet has caused problems in the past;
>>>> perhaps you heard of the slammer worm?
>>>>
>>>> Even with a strongly named assembly you are still open to some kinds of
>>>> attacks.
>>>>
>>>> Finally you may need to communicate data with a web service at some
>>>> point, and I doubt you'd want to provide your key to the 3rd party.
>>>>
>>>
>>>
>>
>>
>
>

> Just curious why people freak out about not having SSL and/or having a
> SQL Server port 1433 open.
>
> If I do the following why do I care about SSL or port 1433?
>
> 1.  40 character passwords for all SQL accounts
> 2.  any sensitive data written to the SQL server is encrypted (via one
> of
> numerous encryption methods provided in .NET 2.0) in the database
> 3.  any sensitive data sent over http is encrypted (via one of
> numerous
> encryption methods provided in .NET 2.0)
> 4.  the encryption key itself is encrypted and stored in a location
> that
> would be hard to find even if someone had admin rights to the server
> and the
> only DLL that can deal with the key is a signed assembly with a strong
> name
> key file.
> 5.  all cookie information that is sensitive is encrypted
> 6.  all "user accounts" (data mining folks) only access data feeds
> (databases) that do not contain sensitive data
> I use SSL to communicate with external sources that require it, but
> they pay for an maintain their certificates.  I do provide split
> tunnel VPN solutions for the more paranoid clients, but it seems to me
> that we've sorta gone overboard on security (applied too many layers).
> I'm all for intelligent security, but not for some of the wacky
> overkill blanket solutions I see out there -- solutions that still
> have vulnerability from user accounts.  The folks that are hacking
> into CC data and the like are doing so because company X had obvious
> open holes (easy to guess user account, using default passwords, etc.
> etc.).
>
> What it seems the end result is, companies that are paranoid, seeking
> blanket solutions, but still vulnerable to simple password/userID
> hacking.
>
> In the systems I design and build, even if a userID/passsword we're
> hacked (extremely unlikely with 40 character passwords on all accounts
> that are meaningful) they would still be confronted with encrypted
> data which will be completely useless to them.  Even if they guessed
> the sa account password and deleted the database that would be a
> hassle (aka gotta get an offsite backup) but still NO sensitive data
> was compromised.
>
> Rob
>

"Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com>
wrote in message news:4580be63198f408c8210fe32ddf08@news.microsoft.com...
> how do you protect against data manipulation on the wire ?? i assume your
> app checks every single piece of data with MAC or a digital signature?
>
>
>
> ---------------------------------------
> Dominick Baier - DevelopMentor
> http://www.leastprivilege.com
>
>> Just curious why people freak out about not having SSL and/or having a
>> SQL Server port 1433 open.
>>
>> If I do the following why do I care about SSL or port 1433?
>>
>> 1.  40 character passwords for all SQL accounts
>> 2.  any sensitive data written to the SQL server is encrypted (via one
>> of
>> numerous encryption methods provided in .NET 2.0) in the database
>> 3.  any sensitive data sent over http is encrypted (via one of
>> numerous
>> encryption methods provided in .NET 2.0)
>> 4.  the encryption key itself is encrypted and stored in a location
>> that
>> would be hard to find even if someone had admin rights to the server
>> and the
>> only DLL that can deal with the key is a signed assembly with a strong
>> name
>> key file.
>> 5.  all cookie information that is sensitive is encrypted
>> 6.  all "user accounts" (data mining folks) only access data feeds
>> (databases) that do not contain sensitive data
>> I use SSL to communicate with external sources that require it, but
>> they pay for an maintain their certificates.  I do provide split
>> tunnel VPN solutions for the more paranoid clients, but it seems to me
>> that we've sorta gone overboard on security (applied too many layers).
>> I'm all for intelligent security, but not for some of the wacky
>> overkill blanket solutions I see out there -- solutions that still
>> have vulnerability from user accounts.  The folks that are hacking
>> into CC data and the like are doing so because company X had obvious
>> open holes (easy to guess user account, using default passwords, etc.
>> etc.).
>>
>> What it seems the end result is, companies that are paranoid, seeking
>> blanket solutions, but still vulnerable to simple password/userID
>> hacking.
>>
>> In the systems I design and build, even if a userID/passsword we're
>> hacked (extremely unlikely with 40 character passwords on all accounts
>> that are meaningful) they would still be confronted with encrypted
>> data which will be completely useless to them.  Even if they guessed
>> the sa account password and deleted the database that would be a
>> hassle (aka gotta get an offsite backup) but still NO sensitive data
>> was compromised.
>>
>> Rob
>>
>
>

>
> I'll admit you folks have pointed out the weakness of my strong name
> DLL --  but I do have some reliance on the  OS -- the attacker would
> need to gain Admin access and then really spend a lot of time hunting
> down my DLL(s) (assuming they have figured out the application
> process) that are being used to do the security processing, then
> decompile and figure out what is what. So I'm not taking complete
> control of security, I do have multiple layers some reliance on
> existing controls.
>
> "Dominick Baier [DevelopMentor]"
> <dbaier@pleasepleasenospamdevelop.com> wrote in message
> news:4580be63198f408c8210fe32ddf08@news.microsoft.com...
>
>> how do you protect against data manipulation on the wire ?? i assume
>> your app checks every single piece of data with MAC or a digital
>> signature?
>>
>> ---------------------------------------
>> Dominick Baier - DevelopMentor
>> http://www.leastprivilege.com
>>> Just curious why people freak out about not having SSL and/or having
>>> a SQL Server port 1433 open.
>>>
>>> If I do the following why do I care about SSL or port 1433?
>>>
>>> 1.  40 character passwords for all SQL accounts
>>> 2.  any sensitive data written to the SQL server is encrypted (via
>>> one
>>> of
>>> numerous encryption methods provided in .NET 2.0) in the database
>>> 3.  any sensitive data sent over http is encrypted (via one of
>>> numerous
>>> encryption methods provided in .NET 2.0)
>>> 4.  the encryption key itself is encrypted and stored in a location
>>> that
>>> would be hard to find even if someone had admin rights to the server
>>> and the
>>> only DLL that can deal with the key is a signed assembly with a
>>> strong
>>> name
>>> key file.
>>> 5.  all cookie information that is sensitive is encrypted
>>> 6.  all "user accounts" (data mining folks) only access data feeds
>>> (databases) that do not contain sensitive data
>>> I use SSL to communicate with external sources that require it, but
>>> they pay for an maintain their certificates.  I do provide split
>>> tunnel VPN solutions for the more paranoid clients, but it seems to
>>> me
>>> that we've sorta gone overboard on security (applied too many
>>> layers).
>>> I'm all for intelligent security, but not for some of the wacky
>>> overkill blanket solutions I see out there -- solutions that still
>>> have vulnerability from user accounts.  The folks that are hacking
>>> into CC data and the like are doing so because company X had obvious
>>> open holes (easy to guess user account, using default passwords,
>>> etc.
>>> etc.).
>>> What it seems the end result is, companies that are paranoid,
>>> seeking blanket solutions, but still vulnerable to simple
>>> password/userID hacking.
>>>
>>> In the systems I design and build, even if a userID/passsword we're
>>> hacked (extremely unlikely with 40 character passwords on all
>>> accounts that are meaningful) they would still be confronted with
>>> encrypted data which will be completely useless to them.  Even if
>>> they guessed the sa account password and deleted the database that
>>> would be a hassle (aka gotta get an offsite backup) but still NO
>>> sensitive data was compromised.
>>>
>>> Rob
>>>