Part of me does not want to contribute anymore to this flamewar (although, lolcow amirite?)
But I need some clarification before I work on a little project:
SestusData Wrote:
-------------------------------------------------------
> To Tx,
> Next, while the request may be coming from the
> users browser, in a man-in-the-middle attack it is
> the fraudsters device that is connected to the
> authenticating website, hence the term
> man-in-the-MIDDLE.
In a browser based MITM scenario it is the legitimate users computer that is connected to the website; hence the "browser based" portion.
> Obviously, the first challenge
> for the fraudster would be to obtain the users
> key, not an easy task in this situation. But lets
> suppose the fraudster could infect the victims
> computer with malware and obtain the key.
Except that it could be read by javascript in the DOM, or if the site isn't using SSL (like your demo site), can just be plucked from the air for a wireless connection (for example).
> Since
> the fraudsters computer is likely different than
> the users, the key would not validate and
> authentication would fail on that point alone.
> But lets suppose the fraudster manages to clone or
> replicate the users device to the authenticating
> website...
Or somehow manages to invent a magical language that can somehow 'script' the behavior of the users' browser.
> the fraudster is still connecting from
> a different IP address. This would render the key
> invalid and authentication would fail.
Except that auth would succeed in the scenario I've laid out
> So, lets
> suppose the fraudster attempts to construct a
> valid key on their own. Even if the fraudster can
> spoof the users IP address to the authenticating
> server, the fraudster cannot construct a valid key
> for that IP without access to non-disclosed
> server-side PKI keys on the authenticating servers
> website which are used in the key exchange.
Nobody needs to validate a new IP, when the users browser would do. Besides I haven't even looked into the potential for using CSRF to add machine profiles or modify contact information.
>
> Finally, XSS is NOT widely used for phishing.
um, yes it is. Not as common as setting up a webpage at myspace.com-index.cfm.com or something, but it's still fairly common.
Although, I'm sure phishers wouldn't utilize XSS anyway, it's not fair to PhishCops(R).
> the point is, even if a
> PhishCops(R)-equipped website had an XSS hole,
> this would have no impact of the PhishCops(R)
> authentication process. It is apples and oranges.
> One is not affected by the other.
Can I quote you on that?
>
> PhishCops(R) is not snakeoil. It is a
> cryptographic multi-factor authentication process
> that uses mathematics algorithms to produce and
> validate PKI keys.
oh shit, nm, I didn't realize you had "mathematics algorithms" on your side.
> Billion-dollar corporations use
> PhishCops(R). So, no, it is not snakeoil.
lol
Considering the other software that Sestus Data is known for (google search brings up some screensavers, some sort of image downloader called WebPirate and a popup blocker called NetPopper), I totally believe the company is offering a Real(R) Solution(R) and not
SnakeOil(R)
btw, this thread is now ~#4 in a google search for "PhishCops"
-tx @ lowtech-labs.org