linux – 可以改进此用户名/密码生成器脚本的安全性吗?
描述
为了管理我的大量网站登录,我写了一个bash脚本 >一个字符串,对我个人而言,标识某个帐户.示例是mylogin@stackoverflow.com或thisWebsiteIVistedLately,但它可能是任何东西.它不必遵循某种模式,它应该帮助我区分我想要管理的不同帐户. 输出是帐户的用户名和安全密码的组合.我不想存储任何生成的用户名/密码,也不存储主密码.因此,类似于Honey Encryption,我希望脚本为每个输入生成合理的结果.如果坏人输入了错误的主密码,他就会得到一个不同的用户名/密码组合,无法区分“真实”密码. 这是我到目前为止提出的bash脚本: #!/bin/bash # robust bash scripting set -o errexit set -o nounset set -o pipefail # external programs OPENSSL=$(which openssl) SED=$(which sed) CUT=$(which cut) # get identifier read -s -p "id = " ID echo "" # read password read -s -p "pw = " PW echo "" # generate username printf "%s" "$ID" | { printf "%s" "$PW" | "$OPENSSL" enc -e -aes-256-cbc -pass stdin -salt -S "0000000000000000" -in /dev/fd/3; } 3<&0 | "$OPENSSL" dgst -sha512 -binary | "$OPENSSL" enc -base64 -A | "$SED" 's/[^a-zA-Z]//g' | "$CUT" -c -8 # generate password printf "%s" "$ID" | { printf "%s" "$PW" | "$OPENSSL" enc -e -aes-256-cbc -pass stdin -salt -S "2222222222222221" -in /dev/fd/3; } 3<&0 | "$OPENSSL" dgst -sha512 -binary | "$OPENSSL" enc -base64 -A | "$CUT" -b -32 如您所见,用户名和密码由生成 >使用AES加密给定主密码的标识符字符串, 我试图让任何方面尽可能安全.对于标识符和密码输入,使用bash内部读取.此外,当密码通过管道传输到openssl时,使用bash内部printf.显然,用过的盐只是占位符.在最后阶段,任何使用该脚本的人都应该替换它们. 例 这是一个例子(假设上面的脚本保存为myscript.sh: $./myscript.sh $id = mylogin@stackoverflow.com $pw = 12345 $CbAMaZar $XFTD9VRwQxFbU4tHKuiJvy5c18oJaDbg 最后两行指定生成的用户名和密码. 现在,假设有人对我有所了解,除了主密码(Kerckhoffs’s principle).坏人来了: $./myscript.sh $id = mylogin@stackoverflow.com $pw = 23456 $MNLManDN $pczRREIy9+ag/0Y7jauAWpm5sllh5sjg 要检查这是否正确,他必须实际尝试生成的登录. 题 现在,我的问题是如何改进此脚本的安全性(在加密和bash脚本方面).当然,如果坏人有root访问权限或知道主密码,则全部丢失.这就是我不打算使用这种方法管理重要帐户的原因. 但是,如果有人知道我的帐户的正确用户名和密码(例如通过SQL注入),则应该没有(现实的)方法来查找我的主密码或任何其他帐户用户名/密码组合.此外,系统上的任何非root用户都不可能找到生成的用户名/密码对或我的主密码. 因此,对于SO的所有安全性,加密技术和编程大师:上面的脚本中是否存在任何安全问题,或者它是否被认为是“安全的”? 解决方法
我一直在为我的用户名/密码使用一个非常类似的方案.到目前为止,它对我来说非常有效.
我要说的第一件事是从标准的加密散列算法开始.据我所知,这个应用程序没有真正需要与加密相结合,你只需要获得一个不可逆的输出回到你的初始密码.使用标准和安全的东西(而不是md5),并确保您的密钥足够复杂,以避免您的密码出现在标准查找表中. 我只是使用类似MyHash(关键网站名称)的东西…你可以通过加密/计算网站名称中的内容并将其作为盐添加回来使其更安全,但是,我个人认为这对于此应用程序来说是过度的…不虽然是安全专家 – 但这实际上取决于你使用它的原因.您最终会平衡易用性与安全性 – 我可以从经验中说,您需要一种可以重新创建的算法(如果必须). 我用了几年就学到了一些东西 – >很多网站都喜欢强制使用最大密码长度,我讨厌这些网站及其代表的所有内容.我被迫将我的base64编码结果截断为19个字符以标准化事物,所以我不必记住我的密码他们截断的任意数量的字符. 我使用标准用户名,所以我的方案与你的方案有所不同,但希望这里的一般想法可以使用. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |