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(a)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(a)lists.sudoroom.org >> https://sudoroom.org/lists/listinfo/access >> >> >