Re: if I encrypt key data why do I want or need SSL?

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.remove@xxxxxxxxxxxxxxxxx> wrote in
message news:erwXGkrUGHA.5500@xxxxxxxxxxxxxxxxxxxxxxx
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" <robains@xxxxxxxxxxx> wrote in message
news:Oqt$gTrUGHA.5808@xxxxxxxxxxxxxxxxxxxxxxx
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" <ajj3085@xxxxxxxxxxxx> wrote in message
news:1143573820.754223.139480@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.







.

Relevant Pages

  • CryptoSurvey -- Results ..
    ... Many same or similar behavioral barriers for the ... effective utilization of many security solutions still exist limiting ... applications of encryption technologies currently in commercial ... Many people do not care about cryptography and/or security products ...
    (sci.crypt)
  • CryptoSurvey -- Results ..
    ... Many same or similar behavioral barriers for the ... effective utilization of many security solutions still exist limiting ... applications of encryption technologies currently in commercial ... Many people do not care about cryptography and/or security products ...
    (sci.crypt)
  • Re: OT - Kuwait
    ... > One place where I agree with you is that the scope of government intrusion ... > into the private matters of Americans is much greater than most Americans ... >>> strict security procedures to prevent unauthorized release of the keys. ... >> Feds Want to Control Encryption ...
    (alt.sports.football.pro.ne-patriots)
  • Re: OT - Kuwait
    ... Making the case for encryption standards that would allow the Feds to ... One place where I agree with you is that the scope of government intrusion ... into the private matters of Americans is much greater than most Americans ... >> strict security procedures to prevent unauthorized release of the keys. ...
    (alt.sports.football.pro.ne-patriots)
  • Re: National Security Backdoor in telnetd - all versions.
    ... >>against the Secret Service for their violations of civil rights. ... encryption techniques to protect critical resources. ... plants have absolutely horrid security resulting from these stupidities. ... Of course I doubt you have an NDA with the government - so ...
    (comp.os.linux.security)