[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [FD] Hilariously Bad SQRL Implementation
From:       Scott Arciszewski <scott () arciszewski ! me>
Date:       2014-08-22 2:13:10
Message-ID: CAPKwhwuiqcEsfFjWe1RW7SVwrah0x4ANPQUECwu37sEeYWPp2g () mail ! gmail ! com
[Download RAW message or body]

> Why would any sane rational human being implement something from Gibson?

On that note, I did come across the attrition charlatan page after I
started this project. But as far as I'm concerned, I'm only implementing an
Ed25519 signature. That the specific client application is one of Steven
Gibson's brain-children is sort of irrelevant to the scope of my
initiative, but I will certainly treat anything he produces with due
skepticism. That being said, just because he has a history of
fraud/incompetence doesn't mean I will immediately discredit SQRL without
evaluating the spec/src, whenever they're available. It deserves a fair
chance and an uncensored review.

> I would implement time proven solutions based on real world testing not
an experimental solution from a rather dubious source.

I suppose libsodium/NaCl would fail to meet some peoples' definitions for
"time proven", but the underlying crypto (Curve25519/Ed25519) is being
implemented in various high profile applications (Tor, Cryptocat, etc.) so
if it fails to pass the test of time, a lot of people will end up with egg
on their face.

> I suppose, as an interesting side project, it might be interesting to
explore but for production, I wouldn't touch with a million foot stick.

I fully agree. I wouldn't recommend either the library I'm building nor the
program/protocol that Steven Gibson produces be used in any production
environment until they have been reviewed by competent hackers and
cryptographers.


On Wed, Aug 20, 2014 at 11:04 PM, Sanguinarious <
Sanguinarious@occultusterra.com> wrote:

> Why would any sane rational human being implement something from
> Gibson? I still remember him saying how implementing raw sockets in
> Windows XP will totally and utterly destroy the entire internet. I
> would implement time proven solutions based on real world testing not
> an experimental solution from a rather dubious source.
>
> I suppose, as an interesting side project, it might be interesting to
> explore but for production, I wouldn't touch with a million foot
> stick.
>
>
> On Sun, Aug 17, 2014 at 8:22 PM, Scott Arciszewski
> <kobrasrealm@gmail.com> wrote:
> > If any of you are familiar with Stephen Gibson's SQRL protocol for user
> > authentication (really neat idea), you might have come across this PHP
> > implementation before: https://github.com/geir54/php-sqrl
> >
> > Unfortunately, this library is actually pretty terrible. Not only does it
> > pass all of the data off to a Heroku app to perform the signature
> > verification, it is also vulnerable to SQL Injection:
> >
> >
> https://github.com/geir54/php-sqrl/blob/0fa574520a1843a33a84c3985f934e84af6f2042/sqrl_verify.php#L39-59
> >
> > I thought about submitting a pull request to fix this, but I don't
> believe
> > there is honestly much here to salvage. So, I'm writing my own
> > implementation here:
> >
> > https://github.com/darkitecht/php-sqrl <- Not ready, at all, for even
> beta
> > testing.
> >
> > P.S. Also, it uses mt_rand() for challenge generation in a crypto
> library.
> > Tsk tsk.
> >
> > _______________________________________________
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[prev in list] [next in list] [prev in thread] [next in thread]