You shouldn't use SHA-1 string as AppleID's security answer

Was it definitely done the same way twice? The result is potentially "wrong" in the blog post:

    $ shasum <<< "answer_1"
    20d3279857198a0d67cce2b531b4d901224029ba  -
    $ echo -n "answer_1" | sha1sum 
    356e11142394c2a087841b9d1d783f16264aa082  -

The difference is the missing newline character. If the hashes were not generated the same way the first time, maybe that's the problem?

methou 10y ago ↗

Looking into the code of the page: <input id="sec-ans-1" name="securityQuestions.questions[0].answer" aria-invalid="true" data-vtype="security" type="text" required="true" value="••••••••" maxlength="32" autocomplete="off">

maxlength = "32" explains everything. Though Apple never said about the length, but it was a positive bias[1] which sometimes people only test samples that support the existing hypothesis.

[1] http://lesswrong.com/lw/iw/positive_bias_look_into_the_dark/

swiecki 10y ago ↗

Here's a more pop-sci explanation of this form of bias from the new york times in case anyone sees these comments. http://www.nytimes.com/interactive/2015/07/03/upshot/a-quick...

sneak 10y ago ↗

"echo -n" suppresses the newline. In one case they are using 'shamus' and in the second 'sha1sum', though.

You shouldn't use SHA-1 string as AppleID's security answer (blog.qzhou.in)

4 comments