
Full Disclosure mailing list archives
Re: Hilariously Bad SQRL Implementation
From: Scott Arciszewski <scott () arciszewski me>
Date: Thu, 21 Aug 2014 22:13:10 -0400
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-59I thought about submitting a pull request to fix this, but I don'tbelievethere 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 evenbetatesting. P.S. Also, it uses mt_rand() for challenge generation in a cryptolibrary.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/
Current thread:
- Hilariously Bad SQRL Implementation Scott Arciszewski (Aug 18)
- Re: Hilariously Bad SQRL Implementation Travis Biehn (Aug 20)
- Re: Hilariously Bad SQRL Implementation Scott Arciszewski (Aug 20)
- Re: Hilariously Bad SQRL Implementation Sanguinarious (Aug 21)
- Re: Hilariously Bad SQRL Implementation Scott Arciszewski (Aug 25)
- Re: Hilariously Bad SQRL Implementation Travis Biehn (Aug 20)