Est-il possible d'inverser un sha1?
est-il possible d'inverser un sha1?
je pense à utiliser un sha1 pour créer un système léger simple pour authentifier un petit système intégré qui communique sur une connexion non cryptée.
disons que je crée un sha1 comme celui-ci avec l'entrée d'une "clé secrète" et l'épice avec un timestamp de sorte que le sha changera tout le temps.
sha1("My Secret Key"+"a timestamp")
puis j'inclus ce sha1 dans la communication et le serveur, qui peut faire la même chose calcul. Et j'espère que personne ne pourra trouver la "clé secrète".
Mais est-ce vraiment vrai?
si vous savez que c'est comme ça que je l'ai fait, vous sauriez que j'ai mis un horodateur là-dedans et vous verriez le sha1. Vous pouvez ensuite utiliser ces deux et de trouver la clé "secrète"?
secret_key = bruteforce_sha1(sha1, timestamp)
Merci Johan
1: Je suppose que vous pourriez forcer d'une façon ou d'une autre, mais combien de travail cela en réalité?
Note2: Je n'ai pas l'intention de crypter des données, je voudrais juste savoir qui les a envoyées.
9 réponses
Non, vous ne pouvez pas inverser SHA-1, c'est exactement pourquoi il est appelé un algorithme de hachage sécurisé.
ce que vous devriez certainement faire cependant, est inclure le message qui est transmis dans le calcul de hachage. Dans le cas contraire, un intermédiaire pourrait intercepter le message et utiliser la signature (qui ne contient que la clé de l'expéditeur et l'horodatage) pour l'attacher à un faux message (où il serait encore valide).
et vous devriez probablement utiliser SHA-256 pour nouveaux systèmes maintenant.
sha("My Secret Key"+"a timestamp" + the whole message to be signed)
vous devez également transmettre le timestamp dans le clear, parce que sinon vous n'avez aucun moyen de vérifier le digest (autre que d'essayer beaucoup de timestamp plausibles).
Si une attaque par force brute est possible dépend de la longueur de votre clé secrète.
la sécurité de l'ensemble de votre système dépend de ce secret partagé (parce que l'expéditeur et le destinataire ont besoin de savoir, mais personne d'autre). Un attaquant tenterait de poursuivre la clé (soit mais Brute-force de deviner ou en essayant de l'obtenir à partir de votre appareil) plutôt que d'essayer de briser SHA-1.
SHA-1 est un fonction de hachage qui a été conçu pour rendre difficile l'inversion de l'opération. Ces fonctions de hachage sont souvent appelés fonctions unidirectionnelles ou fonctions de hachage cryptographiques pour cette raison.
Toutefois SHA-1 a certains a récemment découvert des faiblesses qui permettent de trouver une entrée plus rapidement qu'en faisant une recherche brutale de toutes les entrées. Vous devriez envisager d'utiliser quelque chose de plus fort comme SHA-256 pour les nouvelles applications.
Jon Callas sur SHA-1:
Il est temps de marcher, mais pas l'exécuter, pour les sorties de secours. Vous ne voyez pas de fumée, mais les alarmes incendie sont passés.
La question est en fait, comment s'authentifier sur une session non sécurisée.
la norme pourquoi faire ceci est d'utiliser un condensé de messages, par exemple HMAC.
vous envoyez le message en clair ainsi qu'un hachage d'accompagnement de ce message où votre secret a été mélangé.
Donc au lieu de:
sha1("My Secret Key"+"a timestamp")
Vous avez:
msg,hmac("My Secret Key",sha(msg+msg_sequence_id))
l'id de séquence de message est un un simple contre pour garder une trace par les deux parties du nombre de messages qu'ils ont échangés dans cette "session" - cela empêche un attaquant de simplement rejouer les messages vus précédemment.
norme de l'industrie et sécuritaire façon d'authentifier les messages, qu'ils soient cryptés ou non.
(c'est pourquoi vous ne pouvez pas brute, la valeur de hachage:)
un hachage est une fonction à Sens Unique, ce qui signifie que de nombreuses entrées produisent toutes la même sortie.
comme vous connaissez le secret, et vous pouvez faire une supposition raisonnable quant à la portée de l'horodatage, alors vous pouvez itérer sur tous ces horodateurs, calculer le hachage et le comparer.
bien sûr, deux ou plusieurs horodateurs dans la plage que vous examinez peuvent "entrer en collision", c'est-à-dire que bien que les horodateurs soient différents, ils génèrent le même hachage.
il n'y a donc, fondamentalement, aucun moyen d'inverser le hachage avec certitude.
En termes mathématiques, seulement fonctions bijectives ont une fonction inverse. Mais les fonctions de hachage ne sont pas injective car il y a plusieurs valeurs d'entrée qui donnent la même valeur de sortie (collision).
donc, non, les fonctions de hachage ne peuvent pas être inversées. Mais vous pouvez chercher de telles collisions.
Modifier
comme vous voulez authentifier la communication entre vos systèmes, je suggère à utilisez HMAC. Cette construction pour calculer les codes d'authentification de message peut utiliser différentes fonctions de hachage. Vous pouvez utiliser SHA-1, SHA-256 ou n'importe quelle fonction de hachage que vous voulez.
Et pour authentifier la réponse à une demande spécifique, je voudrais envoyer un nonce avec la demande qui doit être utilisé comme sel pour authentifier la réponse.
il n'est pas tout à fait vrai que vous ne pouvez pas inverser la chaîne cryptée SHA-1.
vous ne pouvez pas inverser directement un, mais il peut être fait avec des tables arc-en-ciel.
Wikipédia: une table arc-en-ciel est une table précomputée pour inverser les fonctions de hachage cryptographique, généralement pour casser les hachages de mot de passe. Les Tables sont généralement utilisées dans la récupération d'un mot de passe en clair jusqu'à une certaine longueur consistant en un ensemble limité de caractères.
essentiellement, SHA-1 n'est aussi sûr que la force du mot de passe utilisé. Si les utilisateurs ont de longs mots de passe avec des combinaisons obscures de caractères, il est très peu probable que les tables existantes arc-en-ciel auront une clé pour la chaîne chiffrée.
vous pouvez tester vos chaînes cryptées SHA-1 ici: http://sha1.gromweb.com/
il y a d'autres tables arc-en-ciel sur internet que vous pouvez utiliser pour Google reverse SHA1.
notez que les meilleures attaques contre MD5 et SHA - 1 ont été de trouver deux messages arbitraires m1 et m2 où h(m1) = h(m2) ou de trouver m2 tel que h(m1) = h(m2) et m1 != m2. Trouver m1, compte tenu de h(m1) est encore infaisable sur le plan informatique.
en outre, vous utilisez un MAC (code d'authentification de message), de sorte qu'un attaquant ne peut pas oublier un message sans connaître le secret avec une mise en garde - la construction générale MAC que vous avez utilisé est susceptible à l'attaque de longueur extension - un l'attaquant peut dans certaines circonstances forger un message m2|m3, h(secret, m2|m3) donné m2, h(secret, m2). Ce N'est pas un problème avec timestamp juste, mais c'est un problème lorsque vous calculez MAC sur des messages de longueur arbitraire. Vous pouvez ajouter le secret à timestamp au lieu de Pré-en attente, mais en général vous êtes mieux en utilisant HMAC avec SHA1 digest (HMAC est juste la construction et peut utiliser MD5 ou SHA comme algorithmes digest).
enfin, vous ne signez que le timestamp et le pas complet demande. Un attaquant actif peut facilement attaquer le système, surtout si vous n'avez pas de protection de replay (bien que même avec la protection de replay, ce défaut existe). Par exemple, je peux capturer timestamp, HMAC(timestamp avec secret) à partir d'un message et l'utiliser ensuite dans mon propre message et le serveur l'acceptera.
mieux envoyer le message, HMAC (message) avec un secret suffisamment long. Le serveur peut être assuré de l'intégrité du message et de l'authenticité de la client.
selon votre scénario de menace, vous pouvez ajouter une protection de replay ou noter que ce n'est pas nécessaire car un message rejoué en entier ne cause aucun problème.
Hachages sont dépendants de l'entrée, et pour la même entrée donnera le même résultat.
donc, en plus des autres réponses, veuillez garder à l'esprit ce qui suit:
si vous démarrez le hachage avec le mot de passe, il est possible de pré-calculer les tables arc-en-ciel, et d'ajouter rapidement des valeurs d'horodatage plausibles, ce qui est beaucoup plus difficile si vous commencez avec l'horodatage.
Donc, plutôt que d'utiliser sha1("Mon Secret Touche"+"timestamp")
aller pour sha1("un timestamp"+"Mon Secret Key")
je crois que l'on a accepté la réponse est techniquement juste mais faux en ce qui concerne le cas d'utilisation: créer et transmettre des données inviolables sur des supports publics/non fiables.
parce que bien qu'il soit techniquement très difficile de forcer ou d'inverser un hachage SHA, lorsque vous envoyez un texte simple "données & un hachage des données + secret" sur internet, comme indiqué ci-dessus, il est possible d'obtenir intelligemment le secret après avoir capturé assez d'échantillons de vos données. Pensez - y - vos données peuvent changer, mais la clé secrète reste la même. Donc chaque fois que vous envoyez un nouveau blob de données, c'est un nouvel échantillon pour exécuter des algorithmes de craquage de base. Avec 2 échantillons ou plus qui contiennent des données différentes et un hachage des données+secret, vous pouvez vérifier que le secret que vous déterminez est correct et non un faux positif.
ce scénario est similaire à la façon dont les pirates Wifi peuvent casser les mots de passe wifi après avoir capturé assez de paquets de données. Après avoir recueilli assez de données c'est trivial pour générer la clé secrète, même si vous n'êtes pas techniquement en train D'Inverser SHA1 ou même SHA256. La seule façon de s'assurer que vos données n'ont pas été altérées, ou de vérifier à qui vous parlez de l'autre côté, est de crypter la totalité des données blob en utilisant GPG ou similaire (Public & private keys). Le Hashing est, par nature, toujours incertain lorsque les données que vous hashez sont visibles.
en pratique cela dépend vraiment de l'application et du but de pourquoi vous êtes le hachage dans la première place. Si le niveau de sécurité requis est insignifiant ou si vous êtes dans un réseau 100% fiable, alors peut-être que le hashing serait une option viable. J'espère que personne sur le réseau, ou tout intrus, n'est intéressé par vos données. Dans le cas contraire, pour autant que je puisse le déterminer à l'heure actuelle, la seule autre option fiable est le cryptage basé sur la clé. Vous pouvez soit crypter la totalité des données blob ou tout simplement signer.
Note: C'était l'une des façons dont les Britanniques ont été en mesure de craquer le code Enigma au cours de la Seconde Guerre mondiale, conduisant à favoriser les Alliés.
des idées sur ce point?
SHA1 a été conçu pour empêcher la récupération du texte original du hachage. Cependant, les bases de données SHA1 existent, qui permettent de rechercher les mots de passe communs par leur hachage SHA.