[sudo-access] magnetic card reader error codes as peoples' card hashes

[Marc Juul]

Integration is definitely doable. The problem is that the previous
scancode_decode.js (the one we currently use) was very incomplete and could
not interpret the characters that inform about errors. In order to detect
the errors the new scancode_decode.js must be used (from the commit I
previously mentioned) but using that scancode_decode means breaking
compatibility. The solution is to use the improved scancode_decode first
and if there are no errors but none of the hashes in the database matched
then retry with the old scancode_decode.

On Wed, Nov 29, 2017 at 5:00 PM, Jake <jake at spaz.org> wrote:

> i definitely do not want to break compatibility with existing codes.
>
> if the commit below can distinguish error codes, it should be integrated
> with
> the present code purely to prevent error codes from being passed along as
> valid
> card reads, is there any reason that can't be done?
>
> does anyone here want to try?
>
>
> On Wed, 29 Nov 2017, Marc Juul wrote:
>
> If you look at this commit:
>>
>>
>> https://github.com/sudoroom/doorjam/tree/208acdc836af3d50baa
>> de168366f920f455c5b42
>>
>> I actually fixed this problem but unfortunately the fix broke
>> compatibility
>> with existing hashes so we never switched over. What is needed is to
>> integrate the old hashing code with this new code so we're backwards
>> compatible. The magic code that ignores errors properly is the `magParse`
>> function in this file:
>>
>> https://github.com/sudoroom/doorjam/blob/208acdc836af3d50baa
>> de168366f920f455c5b42/bin/doorjam.js
>>
>> On Wed, Nov 29, 2017 at 4:46 PM, Jake <jake at spaz.org> wrote:
>>
>> it's still the case that error codes reported by the magnetic stripe
>>> reader are
>>> being used as peoples' card hashes.  this means that a random person
>>> swiping a
>>> random card can get access to omni if the error code matches that hash.
>>>
>>> since the data from the card reader is scrambled and randomized, there's
>>> no
>>> easy way to discern "ERROR - CARD NOT READ" or whatever it's trying to
>>> say
>>> from
>>> ")!#@@@449492837203804720_05/20_" or whatever a normal card would be
>>> reporting.
>>>
>>> substack and i tried to fix this a while ago by counting the number of
>>> bytes
>>> coming from the reader but it wasn't enough.  so blah, now everybody here
>>> knows
>>> and so if you care to look into it we can do that.
>>>
>>> -jake
>>> _______________________________________________
>>> access mailing list
>>> access at lists.sudoroom.org
>>> https://sudoroom.org/lists/listinfo/access
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/access/attachments/20171129/1bd77afb/attachment.html>