iPhone 7 e 7 Plus “hackeados” com um simples gadget de $500

Francisco Ribeiro says:

Eu não disse que são as cifras que limitam o número de tentativas mas sim a técnica usada, lê melhor. E não, não envolve o hardware manter contagem de tentativas porque a técnica usada passa precisamente por terem encontrado um ponto onde essa contagem não existe

Depois falas em que qualquer telemóvel / aparelho pode ser alvo de um número infinito de tentativas pois basta transferir os dados para um computador – também não é bem verdade. Procura saber mais sobre “Secure Element” e conceitos como TCB que é usado por exemplo para pagamentos e perceberás que se pudesses exportar o teu token facilmente, o risco aumentaria muito significativamente.

Falas em hackers e chaves de crypto mas a grande parte dos ataques de bypass no lock screen nem são de força bruta mas sim bugs relacionados com o Siri ou Photos (exemplo: http://gizmodo.com/this-weird-trick-apparently-lets-you-bypass-any-iphones-1789134941 ) e depois também há estes mas é um threat model um pouco diferente pois geralmente precisas de fazer o unlock do device primeiro para ter acesso ao filesystem e Keychain. Os ataques de lock screen como o que exemplifiquei demoram menos de um minuto, btw..

Foi o que fiz e não deu, mas volto a dizer, a maioria das pessoas simplesmente não usa PINs com mais de 6 caracteres e com caracteres. Aceita, é assim, olha à tua volta, não estou a falar das recomendações de segurança, estou a falar da realidade 🙂

Voltando ao tempo, 24 semanas. Quando se fala em criptografia, fala-se em criar formas de proteger informação durante milhares ou milhões de anos, é inaceitável que um iPhone possa ser unlocked em semanas ou meses, é uma falha. A prova disso, é que a Apple corrigiu o bug, pois obviamente discordam de ti e acham que a privacidade das pessoas vale mais do que semanas.

Cumps.

Francisco Ribeiro says:

– Tu disseste “aqui o número de tentativas não é limitado…”, e eu disse em “lado nenhum” é limitado pela cifra! Cifra é uma coisa, contagem de tentativas é outra.

-> Mais uma vez te digo, lê melhor.. eu disse que nao é limitado, nao disse que nao era Ilimitado como pareces estar a responder.

– Também envolve hardware sim senhor – repara bem no “também” que foi escrito. O SoC do iPhone tem um núcleo especializado (Secure Enclave) para os protocolos de segurança e encriptação do iPhone, com firmware próprio. É nesse núcleo que se processa e que mantém em memória própria do núcleo a contagem de tentativas. Isto está documentado pela Apple. Basta pesquisar pelo iOS_Security_Guide.

-> como disse, a técnica usada neste artigo nao envolve nada disso, apenas um loophole onde nao ha contagem de tentativas falhadas.

– Acho que devias documentar-te bastante melhor sobre o que o “Secure Element” faz, mais o que faz a encriptação. Tudo que está em disco/memória flash pode ser copiado para outro lado, há muitas formas para o fazer. O “Secure Element” não impede tal coisa, nem impede que fora do aparelho se possa tentar um número infinito de tentativas. O que permite é que se guardem chaves de encriptação de forma mais segura, preferencialmente chaves longas (diferente de password). É por ter e usar essas chaves longas e seguras que, tal como expliquei para o iPhone, qualquer tentativa de ataque de força bruta fora do aparelho demoraria milhões de anos.

-> estás errado. O Secure Element, é um chip com uma pequena capacidade de armazenamento e controlos incluindo ao nivel de acesso físico que te impedem de facilmente exportares dados como o pkpaymenttoken que é o objecto que contem os tokens usados em pagamentos como se um disco se tratasse. Faz um favor a ti próprio, procura informar-te melhor sobre o conceito, pois é bem importante e usado por outros devices.

Curiosamente, falas em crypto e mencionas que tentativas de força bruta fora do aparelho demorariam milhoes de anos… ainda bem que achas isso. Devias perceber que um período tao reduzido de tempo (semanas ou meses), obviamente reduz a protecçao que se tenta atingir a nivel criptográfico.

– Meu caro uma coisa é o lock screen outra é encriptação! Não é por ultrapassar o lock screen que dados que estão encriptados deixam de estar encriptados. O bypass do lockscreen apenas dará acesso a um pequeno conjunto de dados (como fotos e contactos) que são mantidos desencriptados enquanto está em lock, e só no caso de já ter sido introduzida uma vez a password após o boot do aparelho – necessária para que a chave de desencriptação desses dados fique acessível.

-> mais uma vez, estás errado. O lock screen determina por exemplo que objectos podem ser decifrados e acedidos. Um exemplo óbvio sao todos os objectos da Keychain com o atributo ksecattraccessiblewhenunlocked ( https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlocked ) que só sao decifrados se o device estiver unlocked.

Mesmo colocando isso de parte, acesso ao device implica mais do que pareces ter em conta, pois podes ler emails (ou seja, um hacker pode fazer-te reset a várias contas online e obter o link/codigo de recuperaçao e de repente pode ter acesso a coisas como paypal’s, facebook’s e outras contas).

– A possibilidade de usar uma password alfa-numérica está ali no próprio ecrã que é apresentado quando pede para criar uma password/PIN. Outra vez, “RARISSIMO”, lê o que é questionado!!!!

-> mais uma vez, está errado. Já tinha verificado no meu iPhone mas depois da tua insistência dei-me ao trabalho de procurar na net e não, antes de poderes inserir letras tens de ir a Passcode Options em settings e permitir a opçao “Custom Alphanumeric Code” – que nao é default, como disse – e que é rarissimo alguém usar. Tens aqui um artigo sobre isso https://www.imore.com/how-to-secure-iphone-ipad-strong-alphanumeric-password .

“A prova disso, é que a Apple corrigiu o bug, pois obviamente discordam de ti e acham que a privacidade das pessoas vale mais do que semanas.”

– Hás de me explicar o que é que a correcção tem a ver com discordar, ou onde disse que não tem problemas. O que te disse é que para a maioria das situações com pessoas comuns um ataque demorar vários meses torna-se pouco viável para um criminoso. Mais depressa vende o aparelho por peças do que ficar a acumular aparelhos atrás de aparelhos meses a fio.

-> é verdade que o que dizes, para muitos criminosos, o furto tem principalmente a ver com a venda de peças mas para esses, este tipo de ataques mesmo que rápido nao é o mais interessante pela complexidade envolvida.

O problema é que o iPhone é usado por empresas, por pessoas com grandes responsibilidades e acesso a informaçao muito valiosa para nao falar de celebridades e a segurança também tem de os ter em conta. Mesmo assim, tu ou pelo menos eu provavelmente ficariamos bem descontentes se toda a informaçao no nosso telemóvel fosse feita pública e pelo menos para mim, pensar que é uma questao de semanas ou poucos meses é algo que levo a sério (apesar de conhecer maneiras melhores e mais rápidas de a obter).

“Quando se fala em criptografia, fala-se em criar formas de proteger informação durante milhares ou milhões de anos”

– O tempo de protecção duma cifra depende da chave!

Depende da chave, depende do algoritmo usado, da capacidade computacional do adversário entre outras coisas. O problema aqui é essa protecçao é severamente diminuida devido a um problema que nada tem a ver com a cifra usada.

Francisco Ribeiro says:

Bruno, lamento mas esta é ultima resposta que te posso dar neste forum:

– “aqui o número de tentativas não é limitado…”, deverás rever o que escreves se queres negar o que escreveste. Cifras não limitam tentativas.
-> primeiro, nem é bem verdade que cifras nao limitam tentativas (lê sobre password based derivation functions, exemplo: https://en.wikipedia.org/wiki/Scrypt ) mas como disse o número de tentativas aqui é limitado pela logística inerente à técnica usada, já o disse antes. Pareces indiciar que disse mas se leres novamente verás que nao, sai dessa, ouve um pouco.

– a técnica usada? A afirmação que fiz é sobre a realidade do que se passa no iPhone, para evidenciar separação entre cifra e contagem! Haver a falha não significa que não haja contagem envolvendo hardware.

-> a falha é precisamente no facto de NAO haver contagem neste ponto nem por software nem hardware, por isso nao vale a pena contrariares-me e falar do que acontece em geral pois nao se aplica aqui.

– Nada do que estás para aí a dizer tem alguma coisa a ver com poder ou não transferir o que está guardado na memória flash num smartphone!!! Lê o que te dizem. O Secure Element no SoC guarda as chaves que possam ser geradas, não impede que os dados em memória flash possam ser transferidos – a memória flash pode ser removida do aparelho, só como exemplo.

-> o secure element impede que certas chaves sejam exportadas fora do iPhone. Claro que podes exportar tudo o que está na flash do device mas falaste em que se podia sempre exportar tudo e isso nao é verdade, pelo menos até estares disposto a investir milhoes para encontrar uma forma de recuperar a informaçao do secure element.

– Devias perceber que o período de tempo depende da chave [ou password no aparelho]! Se a pessoa escolhe uma má password (curta, não complexa e comum) não há nada que valha, até com limitações de tentativas.
-> estamos de acordo aqui, nao me vês a discordar em lado nenhum.

– Aprende um pouco sobre o que as coisas significam! Não é por haver um bypass ao lock screen, que fica em estado “unlocked”. O uso das chaves criptográficas dependem da inserção correcta da password, isto é, a password é um passo necessário. Mais uma vez lê o iOS_Security_Guide.
Tal como disse alguns dados continuam “desencriptados” após a primeira vez que se insere a password (deixa de funcionar se for reiniciado), mas não me parece que tenhas acesso a envio de emails com o bypass ao lock screen. Os bypass têm sido bastante limitados naquilo que permitem

-> no essencial aqui até estás correcto mas o problema é o email usa um atributo diferente do que enunciei antes que só exige unlock pelo menos uma vez depois de boot (por razoes de usabilidade). Por este motivo, se a estiver em background, um lock screen bypass pode-te dar acesso como já aconteceu. Já fiz muitos assessments de security a aplicaçoes iOS, nao estou aqui para te contrariar mas para te tentar ajudar, tenta ouvir mais.

– Mas quais senttings? A opção está no próprio ecrã para definir a password, não é preciso ir a settings quando se cria pela primeira vez! Voltas a insistir em RARISSIMO sem qualquer ponta de justificação!
-> a opcao está em “Passcode options” a qual nao tens de carregar se queres mudar de passcode e uma pessoa nem sabe necessariamente para que serve pois nao precisas de ir a esse menu para mudar o código. Mais importante, é que isto é algo que nao é definido por omissao e como tal, nao é surpresa que em vários devices que analisei, so me lembro de uma vez ter sido usada. Sim, volto a dizer é muito raro alguém definir passwords alfa-númericas em iphone e com mais de 6 caracteres, o teu grupo de contactos pode nao ser a melhor amostra para analisar o problema do ponto de vista estatistico.

– Eu tive todo o cuidado de referir pessoas comuns, pessoas desconhecidas do criminoso. Ter à partida um alvo determinado cai automaticamente fora do que disse, e não me vais dizer que esses casos representam a maioria das pessoas.
Muitas empresas definem políticas de segurança sobre os aparelhos, entre elas o tipo de password que pode ser usado – o iOS permite um leque alargado de políticas de segurança para ambientes empresariais! Quem trabalha na área saberia que não se deve confiar em PINs, até porque já noutras alturas foram descobertas formas de contornar a limitação no número de tentativas.

-> claro que VIP’s nao sao a maioria mas sao uma minoria muito importante (por definiçao) e agora começas a falar em MDM, sim as empresas podem forçar algumas settings aqui mas há limites grandes em termos de usabilidade no quao se pode complicar a passcode. Sempre que fazes reboot tens de a inserir de novo e se obrigas a que as pessoas escolham passwords fortes, frequentemente tens o efeito secundário que é essas pessoas escreverem o código em post-its ou procurarem uma forma de escolher uma password forte o suficiente para o sistema estar content mas com baixa entropia e fácil de descobrir. Se quiseres discorda, mas o importante aqui é que se estás à espera que todas as empresas implementem uma política de passwords fortes como soluçao entao espera sentado, o problema persiste.

Francisco Ribeiro says:

– O algoritmo criptográfico do scrypt não limita número de tentativas! “password based” key “derivation functions” não é sobre limitar o número de tentativas.
Se queres insistir nessa tua reinterpretação, então a frase é redundante, sem sentido de existir.
-> reduz o número de tentativas que consegues fazer por unidade de tempo do qual todos estamos limitados. É aliás muito importante a sua utilizaçao por essa razao vs algoritmos como MD5 mas este é um tema diferente, concordo. Isso nao se trata de uma reintrepretaçao, a minha resposta foi que a limitaçao de numero de tentativas nao é relacionada com cifras mas pela tecnica usada. Tu tens dito várias vezes que nao sao as cifras que asseguram o numero de tentativas como a querer contrariar-me mas ainda n paraste para ler que é algo que sempre disse.

– Continuas a querer ignorar que a afirmação sobre hardware serviu para frisar a separação entre algoritmo e contagem. Não tem nada a ver com contrariar, já que a falha de contagem é a notícia, tu é que decidiste não aceitar uma característica no iPhone.
-> Mais uma vez, o problema nao tem a ver com o algoritmo de cifra pelo que frisar a separaçao entre algoritmo e contagem ou é irrelevante se se refere em geral (como agora tens vindo a interpretar) ou é errado porque aqui nao há contagem nem software nem hardware precisamente por causa desta falha.

– Meu caro, as chaves não são os dados encriptados, aliás nem é a primeira vez que que me refiro a memória flash, é por isso cómico que só agora, passados todos estes comentários, venhas argumentar um preciosismo que em nada altera o argumento inicial sobre a capacidade para poder sempre fazer um número ilimitado de ataques a dados encriptados em smartphones, ainda mais quando no comentário com essa afirmação identifiquei logo a existência de chaves guardadas que não estão acessíveis ao exterior (“…chave de encriptação que não é acessível fora do aparelho”)

-> estas a misturar coisas. O Secure Element foi para te contrariar qd dizes que consegues exportar tudo do telemovel e é só uma questao de numero de tentativas em força bruta. Nem tudo é uma questao de força bruta – há dados preciosos que nem cifrados consegues exportar, como o token usado para Apple Pay, nao é de todo um “preciosismo”.

– Não vi ainda nenhum bypass que permitisse enviar emails, é isso que disse, como um contraponto ao teu argumento que poderia ser usado para fazer reset a contas, etc. Está mais atento.

-> nao viste porque nao queres ver, é fácil encontrar:
https://www.theverge.com/apple/2013/9/19/4749560/ios-7-lockscreen-security-loophole
https://ios.gadgethacks.com/how-to/siri-exploited-bypass-iphones-lock-screen-browse-contacts-make-calls-send-emails-texts-ios-7-1-1-0154817/
http://phone-rebel.com/ios-8-0-2-lockscreen-bypass-discovered-works-8-1-7-1-2/

portanto nao, mesmo sem o telemóvel estar de facto em estado unlocked, é de facto um grande problema ter estes bypasses, nomeadamente pelo que podes fazer com acesso ao Email.

– Ter uma password alfa-numérica continua a ser uma opção que não precisa de nenhuma mudança em settings quando se cria pela primeira vez. Também não será o teu grupo que define e que te permite dizer que é Rarissimo.

-> é necessário em todas as restantes. Concordo qd dizes que nao é o meu grupo de amigos a melhor amostra estatística mas também n é a esses que me refiri mas sim à maioria das pessoas que nao sabem fazer isso ou n se importam. É senso comum, que a maior parte do pessoal simplesmente não tem screen locks com mais de 6 caracteres e com caracteres alfa-numericos. Se fosses um bocadinho mais sério, já tinhas aceite algo tao óbvio. A tua aproximaçao foi no tom “quem és tu para dizer”, sou alguém que costuma analisar a segurança em empresas e infraestruturas críticas com pessoas que se preocupam muito mais com segurança do que a média, e mesmo assim nem aí vejo isso mas basta olhar à volta.

– Não podes falar como problema em empresas e ignorar que é nas empresas que haveria atenção à política de segurança. Uma password alfanumérica de 6 ou 8 caracteres definida pela pessoa não demora tempo nem requer nada de especial da pessoa ao ponto de ter que usar post-its. Isso já dá uma protecção muito considerável no iPhone. Se for uma password alfa-numérica com símbolos equivale a milhares de anos em ataque de força bruta ao iPhone à velocidade máxima que o sistema de encriptação permite.

-> já revi as configuraçoes de MDM em muitas empresas e sim, é um problema difícil. Alguns porque nao sabem que podes fazer isso, outros porque nao querem saber e outros ainda porque chegaram à conclusao que apesar de aumentarem os requisitos em termos de passwords, as pessoas procuram contornar isso com passwords mais longas mas com baixa entropia. Há quem chame a este problema ‘Password1’, dos tempos em que malta que também achou que era fácil e que nao requer nada de especial escolher uma password melhor e criaram regras que impedem o uso por exemplo da password ‘Password’ e o que aconteceu? Password1 passou a ser a norma:
https://www.pcmag.com/g00/article2/0,2817,2401118,00.asp

(isto teve lugar no mundo das workstations onde as pessoas têm teclados físicos que até facilitam escrever passwords mais fortes do que num iPhone)

Francisco Ribeiro says:

– Isso é uma piada? Limitação por unidade de tempo é o que ocorre e continua a ocorrer no iPhone, é por isso que um simples PIN de 4 dígitos não demora segundos a ser atacado, em vez das horas que demora neste ataque. O que foi ultrapassado foi a limitação ao número de tentativas – 10 no total. E a minha afirmação era que não são os algoritmos a limitar o número de tentativas, o ponto de ataque em que tu próprio pegaste.

-> Por favor pára de insistir, não são os algoritmos que o limitam aqui, continuas a contrariar algo que estamos de acordo. Falei do SCRypt numa divagação em que também disse que era um contexto diferente mas não foi o Scrypt que nos trouxe até aqui. Desde o ínicio que estou a dizer que a limitação do número de tentativas por unidade de tempo é na técnica usada.

É por isso completamente incompreensível que uses um exemplo desses (uma limitação no scrypt) quando não tem nada a ver com a limitação que se estava a falar. Pior é que achas que vens com conceitos novos quando já existem no iPhone.
Ok, preferes que seja vista como uma frase redundante em vez dum erro…
-> É bastante evidente que estás à procura de um escape para justificares-te por estares a bater numa coisa em q nunca discordei.Não falei em limitação do Scrypt no caso do iPhone, como disse acima, e já agora o Iphone nem usa Scrypt.

– Não, não é irrelevante porque o argumento era sobre algo geral – não serem cifras a fazer contagem (tudo na mesma frase, reparaste?). Tu é que pelos vistos preferes ignorar o que a frase diz…
-> ao principio n era, depois como viste q n se aplicava aqui, passou a geral. É por n se aplicar aqui que disse q era irrelevante, se retirarmos o contexto da conversa sim, tudo pode ser relevante.

– Estou a misturar coisas? Como é que estou a misturar coisas quando no comentário em que falo em dados encriptados digo que há chaves guardadas que não são acessíveis fora do aparelho? É assim tão complicado perceber a que cada coisa se refere? O argumento continua válido sobre o ponto que levantei – haver a possibilidade dum número infinito de tentativas para um ataque, que o tempo é que é a real defesa em encriptação.

-> A mistura tem que ver com a ideia de que podes obter tudo é só uma questão de força bruta. Mesmo com tempo infinito, não consegues obter algumas coisas com os tokens de pagamento e tive de discordar qd chamaste a isso um preciosismo.

– Ser necessário em todas as restantes não faz desaparecer que a pessoa teve uma primeira vez. Minoria é uma coisa, RARISSIMO é simplesmente um exagero que não tens como defender dessa maneira.

-> Raríssimo para mim o limite de tentativas por unidade de tempo não está nas cifras ou no hardware criptográfico mas no facto do teste requerer um reboot para fazer novamente, um side effect da técnica usada. Está é uma ideia que tens vindo a repetir várias vezes contra mim, sem motivo, tens de aplicar a ti.

Francisco Ribeiro says:

– Tu nunca antes disseste número de tentativas por unidade de tempo.

Verdade, nao disse por unidade de tempo explicitamente mas devia ser evidente no contexto. Eu percebi que é isso q te tem estado a confundir no que tenho dito daí o ter dito agora.

– Nem essa limitação conseguiria resolver um ataque a PINs segundo a exigência das críticas que tu tens feito à dimensão desta falha no iPhone. Ou será que querias que demorasse dezenas de minutos cada vez que precisasses de desbloquear o teu aparelho?

-> Usar-se um algoritmo como SCrypt nao implica dezenas de minutos para desbloquear o iphone, nem se aplica aqui, enfim.

– Disse “conceitos”!!!!!!!!!! Scrypt não é um conceito, é um algoritmo!! O iPhone usa os mesmos conceitos que vieste mencionar: limitação de tentativas por unidade de tempo e derivação de chaves (longas) a partir da password com criação duma hierarquia de chaves (password based “key” derivation functions).
Não disse que falaste “em limitação do Scrypt no caso do iPhone”, disse que usaste uma limitação do scrypt (limitação por unidade de tempo) vs a limitação do número de tentativas (o que se estava a falar e a falha), ou seja coisas diferentes!

-> se limitas o número de tentativas por unidade de tempo, estás também a limitar o número de tentativas pois ninguém tem tempo infinito mas eu mesmo disse que eram coisas diferentes no mesmo comentário, mas resolveste nao ler. Repito-me: Não discordo qd dizes que são coisas diferentes.

– Ao princípio não era? Está tudo na mesma frase, é tudo sobre não serem os algoritmos a fazer a contagem, “é outro tipo de software”, em que digo que no iPhone isso também envolve hardware, para frisar que não é só software.

-> pois mas nao devias frisar tanto isso como que a contrariar algo que eu nem disse pois nao se aplica aqui, a falha passa precisamente por n haver contagem.

– Meu caro, se no mesmo comentário digo que as cifras não são acessíveis, não é preciso ser um génio para entender que os dados mencionados não incluem cifras, que se referem ao disco, memória flash!! De modo que é um preciosismo teu sobre português numa parte do comentário, ou falta de atenção.

-> as cifras não são acessíveis? Dados mencionados não incluem cifras? Quando dizes “cifras” deves querer dizer “chaves”, misturada de conceitos as cifras não são coisas que se armazenam, são conceitos abstractos..

O preciosismo chama-se Apple Pay, onde dados exportados fora do flash com ou sem crypto, são irrelevantes e por ser usado para português é bem relevante, considero.

– O iPhone aplica um tempo mínimo ao processamento de cada tentativa. Só porque o ataque ainda demora mais do que esse limite não significa que esse mecanismo não exista no iPhone. Podes ler sobre isso na documentação da Apple.

-> o tempo de “processamento de cada tentativa” é importante sim, mas aqui a técnica usada no ataque impõe um tempo por tentativa muitissimo maior por razoes q nada têm a ver com segurança mas com o ter de se fazer reboots para regressar à mesma posição, um side effect portanto. Por curiosidade, se a limitação aqui fosse apenas essa, em menos de 12 dias tinhas qualquer lock screen aberto para PINs com até 6 números.

Francisco Ribeiro says:

Esta terá mesmo de ser a última resposta que te dou. Por favor esforça-te mais por ler e interpretar.

-> primeiro – já tenho dito várias vezes que crypto nao é explorada neste ataque, é que insistes em falar de crypto e depois também falei sobre crypto qd te oiço a dizer coisas como “as cifras sao armazenadas aqui e ali”. O teu comentário inicial foi “Encriptação sempre usou a variável tempo como defesa. Tempo é um factor limitante para que a realização de alguma coisa se torne útil, ou seja, viável.” – nada a ver com o ataque aqui, nada que limite o que quer que seja neste contexto.

segundo – se fosses fazer um ataque de força ao nível criptográfico contra o PIN, sem SEP, apenas força bruta num ataque offline contra um PIN de até 6 caracteres (mesmo que tenhas letras) demorarias bem menos do que o ataque referido deste artigo. Da última vez que fiz uma coisa parecida demorou-me 20h.

-> qualquer algoritmo criptográfico por si só é incapaz de proteger PINs tao fracos como os que tenho falado, pelo menos sem adicionares mais entropia na chave.

-> cada tentativa tem um custo temporal e o teu tempo é limitado, pelo que o teu número de tentativas também é limitado, já expliquei isto antes. Esta diminuição pode-se medir e até se pode configurar através dos parametros de inicializaçao de Scrypt. A tua frase era de que o algoritmo criptográfico nao limita tentativas e aí Scrypt exerce de facto um controlo a esse nível mas nao disse q era ao nível de contagem (há mais do que uma forma de limitar número de tentativas) e nesse mesmo comentário regressei ao tema que te referes e elaborei sobre ele. Como também já disse, é uma limitaçao de natureza diferente, nao me ves a dizer que há contagens no Scrypt em lado nenhum.

-> Pois nao, mas quer dizer que o processo de contagem por software ou hardware nao se aplica aqui (simplesmente NAO HA!), pelo que ao dizeres que é outro processo que faz a contagem e nao a cifra (como ninguém disse) e dizer que é por software ou hardware está desenquadrado e não é relevante aqui. Quando mais vezes falas nisso, mais vezes falas em algo que nao tem relevo para a falha aqui.

-> o problema é q sao vários “lapsos” e nao sao de portugues, só ali sao 2 ou 3 mas podia enunciar muito mais, bem como, o facto de trazeres várias vezes assuntos que nao têm qualquer relevo para tentar explicar o q se passa neste ataque só porque provavelmente pensas que sao uma grande novidade. É evidente que estes sao assuntos que ainda nao conheces em profundidade (o que nao tem absolutamente nada de mal) e torna-se tentador para mim tentar ajudar talvez pq ja fui professor na univ. A unica coisa de mal, é a tua dificuldade em ler e interpretar.

-> a distinçao também é irrelevante neste contexto e eu nunca discordei dela. Fiz apenas o reparo de que o ataque de força bruta contra os dados armazenados mesmo que bem sucedido, nao te dá acesso a tokens de pagamento, pelo que o problema de obter tudo o que está no telemóvel nao se resume a isso. É um reparo importante porque se refere ao Apple Pay 🙂

-> a limitaçao aqui nao existe, isto é, não é aí que está o bottleneck. O que tu chamas “processamento do algoritmo” (presumo que esteja a referir ao calculo da hash Scrypt que neste caso n é Scrypt mas PBKDF2) é muito rápido face ao custo de fazer uma tentativa através da tecnica aqui usada. Estás a contrariar algo q eu n disse mais uma vez.

Concordo com o que dizes no fim sobre passwords fortes, ainda me lembro quando dizias que 24 semanas era muito tempo. Se fosse assim tanto tempo então, na tua lógica não precisarias das tais passwords longas e alfa-numéricas mas ainda bem que achas que são precisas.