Question

描述

为了管理大量的网站登录，我写了一个bash脚本，其中包含

一个字符串，就我个人而言，它标识某个帐户。例如mylogin@stackoverflow.com或thisWebsiteIVistedLately，但它可能是任何东西。它不必遵循某种模式，只是应该帮助我区分我想要管理的不同帐户。
主密码。

输出是帐户的用户名和安全密码的组合。我不想存储任何生成的用户名/密码，也不存储主密码。因此，类似于Honey Encryption，我希望脚本为每个输入生成合理的结果。如果一个坏人输入了错误的主密码，他就会得到一个不同的用户名/密码组合，无法区分＆＃34;真正的＆＃34;之一。

这是我到目前为止提出的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 "1111111111111111" -in /dev/fd/3; } 3<&0 | "$OPENSSL" dgst -sha512 -binary | "$OPENSSL" enc -base64 -A | "$CUT" -b -32

如您所见，用户名和密码由

使用AES
使用SHA，
执行base64转换，
sed并cut输出为用户名和密码的合理格式。

我尽量使任何方面都尽可能安全。对于标识符和密码输入，使用bash内部read。此外，当密码通过管道传送到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的所有安全性，加密和编程大师：上面的脚本中是否存在任何安全问题，或者是否可以考虑＆＃34;安全＆＃34;？

Answer 1

我一直在为我的用户名/密码使用非常类似的方案。到目前为止，它对我来说非常有效。

我要说的第一件事就是从标准的加密散列算法开始。据我所知，这个应用程序没有真正需要与加密相结合，你只需要获得一个不可逆的输出回到你的初始密码。使用标准和安全的东西（不是md5），并确保您的密钥足够复杂，以避免您的密码出现在标准查找表中。

我只是使用像MyHash（key + sitename）这样的东西......你可以通过加密/计算网站名称中的内容并将其作为盐添加回来使其更加安全，但是，我个人认为这对于此应用程序来说太过分了......虽然不是安全专家 - 但这实际上取决于你使用它的原因。您最终会平衡易用性与安全性 - 我可以从经验中说，您需要一个可以重新创建的算法（如果必须）。

我用了几年就学到了一些东西 -

许多网站都喜欢强制使用最长密码长度，我讨厌这些网站及其代表的所有内容。我被迫将我的base64编码结果截断为19个字符以标准化，所以我不必记住我的密码+他们截断的任意字符数。
使用标准内容，以便在远离计算机时重现密码。
有时候这个方案会随机生成一个密码，这个密码都是字母，尽管优于99.9％的密码，但是你所使用的网站会宣布弱/不适合。你可以做的不多 - 我只是添加一个数字/增量，直到它停止抱怨。

我使用标准用户名，因此我的方案与您的方案有所不同，但希望这里的一般想法可以使用。

可以改进此用户名/密码生成器脚本的安全性吗？

描述

实施例

问题

1 个答案: