|
|
Posted by "david forums" on 10/20/67 11:19
Why don't you try to get interactivity with ID machin which is unique, or
with mac address.
David
Le Tue, 21 Jun 2005 12:50:23 +0200, Shaw, Chris - Accenture
<cshaw@revenue.ie> a écrit:
>
> "(thus Philip Zimmermann got arrested for violating the weapons law when
> he
> created PGP)"
>
> I thought he got arrested because he exported PGP out of the US, not
> because
> he created it.
> He was told that PGP could not leave the US via any electronical form,
> compiled or uncompiled, because of the encryption level. He didn't break
> that
> condition and got it out via a book and someone outside the US scanned
> in the
> book and compiled the source code, but they arrested him anyhow.
>
> Probably some urban myth that I heard somewhere.
>
> As for the browser topic, you cannot control what the client browser is,
> or
> whether it has any naughty plugins. The responsibility is on the user,
> once
> the data has left the server via HTTP.
>
> Didn't the UK banks try to implement something like that for the online
> banking, you could only use Internet Explorer, which sparked a debate in
> the
> Linux/Unix world. This was easily spoofed.
>
> -----Original Message-----
> From: Rene Brehmer [mailto:plasticbunny@metalbunny.net]
> Sent: 21 June 2005 09:12
> To: php-general@lists.php.net
> Subject: Re: [PHP] Re: security question...??
>
>
> *************************************
>
> This e-mail has been received by the Revenue Internet e-mail service.
>
> *************************************
>
> However secure you try to make a web application, even with encryption,
> it
> still does not hinder anyone from putting a packet sniffer on your client
> and grab whatever sensitive information you send out.
>
> And if a hacker really wanted to get hold of your sensitive information,
> he
> wouldn't actually have to use a typical browser or anything similar to do
> it, nor is it likely he would. There's nothing to hinder for talking to
> your HTTP server using manually entered commands in a telnet client.
>
> My information 'bout the US approach to encryption may be a little out of
> date, but for the longest, using anything stronger than 40 bit encryption
> was illegal, unless the CIA knew the extra bits above 40 (thus Philip
> Zimmermann got arrested for violating the weapons law when he created
> PGP).
> All that mess did change something, but there's still limitations to what
> you can do in regards to encryption, that don't exist in any other
> country.
> 9/11 didn't exactly help that in any way.
>
> But nevertheless, for every way you can come up with ensuring that your
> client is using a secure application, there's atleast as many ways to
> make
> a program that fools your tests, and then you're back to where you came
> from. The thing I said about where your responsibility ends, is simply
> that
> when you tell a client to use this and that software to access the data
> in
> your remote application, then you can't really prevent them from using
> software that they think is right, but isn't. There is no reliable way,
> with current technologies, of determining whether or not a client's
> software is what it says it is or not. I think it falls under implicit
> trust ...
>
>
> It reminds me of those websites that checks for the version of your
> browser, and refuses to work if you don't have one they like, that falls
> completely short when you visit them with Firefox because it has Mozilla
> and ver. 1 in its ID string, and the sites think it's a Netscape 1 ...
> point being that you can't blindly trust what the client software tells
> you
> ... I don't honestly see any way of doing what you want, without also
> being
> able to see how it can be fooled...
>
>
> Rene
>
> Documented research indicate that on Mon, 20 Jun 2005 17:50:25 -0700,
> "bruce" wrote:
>
>> rene..
>>
>
>> from my perspective, i strongly disagree...
>>
>
>> if you're going to be writing apps that deal with sensitive information,
> you
>> better damm well give some thought as to how secure the client is, or
>> even
>> if the client is actually valid!
>>
>
>> while i'm not precisely sure as to how you'd go about ensuring that the
>> client is indeed real/valid, and not faked, there are some reasonable
>> approaches that the vendor/manufacturer could take, or make available
>> that
>> could go a good way towards satisfying the issue somewhat...
>>
>
>> and creating a secure client/server connection that only the two parties
>> (server/client) can listen to is not illegal in the US.. i'm not sure
>> where
>> you get your information..
>>
>
>> but my point was not regarding tha actual communicatino pipe/wire. there
> are
>> already methods of securing the wire conversation betwen the
>> server/client.
>> i'm concerned with being reasonably sure that the client i'm talking to
>> is
>> indeed a valid/real client. IE, if it identifies itself as IE, then it
>> actually is IE, and not some spoofed app, that acts like IE, that might
>> be
>> sending data to who knows where...
>>
>
>> -bruce
>
> --
>
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
>
> ************************
>
> This message has been delivered to the Internet by the Revenue Internet
> e-mail service
>
> *************************
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Navigation:
[Reply to this message]
|