Hacker Newsnew | past | comments | ask | show | jobs | submit | ryanlm's commentslogin

I'm assuming that the relevant code, is simply an if statement checking for the existence of the url parameters, not even checking if the security questions are correct.

    if(isset($_GET['securityQuesiton0')) {
        // success, 
    }
This is negligence on the developers part and I think they should be disciplined.


Or they designed it to show a variable number of security questions (so management could come along and say "we need 4 questions now" without causing havoc). Then they'd iterate through the responses, verifying them against the appropriate question. Simply forgetting to enforce that the number of questions asked has to equal the number of responses sent would cause the described vulnerability.


That doesn't actually make sense, since the exploit is to leave securityQuestion0 unset...


Who are these people init'ing the attacks? They seem like talented folks.


Yesterday I had to store integers as keys in a map. It's good to learn today that they are implicitly converted to strings. Yes I could have used an array, but that would of required me to know the max index I would suppose. Maybe in JavaScript I insert into the array at any index, but that doesn't seem usual to me, coming from a C background I'd allocate the max index + 1.


I'm not a JavaScript expert but I believe most serious JavaScript implementations can represent sparse arrays, or arrays with holes in the range of indices, for this reason.


Vaguely relevant/example: http://imgur.com/7Bf3hLZ


If performance is important, I believe it's still a fair bit faster to use a plain object as hash, rather than a Map. (If the keys are integers V8 may initially treat the object as an array, but it'll switch over to dictionary mode pretty quickly.)


just be glad it didnt store random integers as floats (happened to me when storing integer timestamps into webstorage)


Doesn't that popular software that tracks you tell you to install by piping the output of curl. I think it's call Brew Ware.


Interesting use of the JNI. Why did you need to use JNI?


Well, the JNI means you get to run native code. For something like this, I think that's actually a requisite. My reasoning would be

a) This is real-time and could potentially be disrupted by GC pauses

b) JNI means you get to use OpenSL, the best and lowest latency sound engine on Android

c) This builds on top of libquiet, a C library, which itself builds on liquid dsp, another C library. Rewriting these in Java would be significantly more work than building the JNI wrapper. Especially true for liquid which is a mature library with lots of code


So why not JNA then?


How exactly did you set up this fail over scheme? You run your own instance of bind. And I'm amusing your listing your domains NS records as your own, and another parties (e.g. cloudflare, etc)?


I’m not running BIND. I got tired of that program. Right now I’m using PowerDNS. Quite a bit overkill, but that server is extremely lightly loaded.

I’m not using CloudFlare, either. That’s the point. If I use CloudFlare CDN, then I depend on CloudFlare’s DNS servers.

The way it works is that DNS servers often have a master/slave relationship. The master sends all the records to the slave once in a while. What you’re supposed to do is list your own server and another server as two separate NS records, and then any client can contact either server for any record. What I’m doing is a hidden master setup. Neither NS record refers to the master, but both point to separate slaves.

There are some downsides. You must assume that any record is public, not private. DNSSEC white lies[0] (and black lies[1]) are not available. And it’s more difficult to use a CDN. But I’m not running a web site right now, so that doesn’t matter to me.

[0] https://blog.cloudflare.com/dnssec-complexities-and-consider...

[1] https://blog.cloudflare.com/black-lies/


Great comment. And I want to point out that no matter how privileged you are in America, Government pretty much has the final say.


that's not the right number.


Zuck's charity.


Flagged? Interesting.


Meta-discussions are often flagged because they're less likely to be intellectually interesting, but this one seems to be proceeding reasonably so we can try turning the flags off for now.


Agreed.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: