If you use a GUID as a password for a publicly facing application as a means to gain access to a service, is this security through obscurity?
如果您使用GUID作为面向公众的应用程序的密码作为获取服务访问权的手段,这种安全性是否通过默默无闻?
I think the obvious answer is yes, but the level of security seems very high to me since the chances of guessing a GUID is very very low correct?
我认为明显的答案是肯定的,但是对我来说安全级别似乎很高,因为猜测GUID的可能性非常低是正确的吗?
Update
The GUID will be stored in a device, when plugged in, will send over the GUID via SSL connection.
GUID将存储在设备中,当插入时,将通过SSL连接通过GUID发送。
Maybe I could generate a GUID, then do a AES 128 bit encrption on the GUID and store that value on the device?
也许我可以生成GUID,然后在GUID上执行AES 128位加密并将该值存储在设备上?
12 个解决方案
#1
13
In my opinion, the answer is no.
在我看来,答案是否定的。
If you set a password to be a newly created GUID, then it is a rather safe password: more than 8 charcters, contains numbers, letters ans special characters, etc.
如果您将密码设置为新创建的GUID,则它是一个相当安全的密码:超过8个字符,包含数字,字母和特殊字符等。
Of course, in a GUID the position of '{', '}' and '-' are known, as well as the fact that all letters are in uppercase. So as long as nobody knows that you use a GUID, the password is harder to crack. Once the attacker knows that he is seeking a GUID, the effort needed for a brute force attack reduces. From that point of view, it is security by obscurity.
当然,在GUID中,'{','}'和' - '的位置是已知的,以及所有字母都是大写的。因此,只要没有人知道您使用GUID,密码就更难破解。一旦攻击者知道他正在寻找GUID,蛮力攻击所需的努力就会减少。从这个角度来看,它是默默无闻的安全。
Still, consider this GUID: {91626979-FB5C-439A-BBA3-7715ED647504} If you assume the attacker knows the position of the special characters, his problem is reduced to finding the string 91626979FB5C439ABBA37715ED647504. Brute forcing a 32 characters password? It will only happen in your lifetime, if someone invents a working quantum computer.
不过,请考虑以下GUID:{91626979-FB5C-439A-BBA3-7715ED647504}如果您认为攻击者知道特殊字符的位置,则他的问题将减少为找到字符串91626979FB5C439ABBA37715ED647504。暴力迫使32个字符的密码?它只会在你的一生中发生,如果有人发明了一台有效的量子计算机。
This is security by using a very, very long password, not by obscurity.
这是安全性,使用非常非常长的密码,而不是默默无闻。
EDIT: After reading the answer of Denis Hennessy, I have to revise answer. If the GUID really contains this info (specifically the mac address) in a decryptable form, an attacker can reduce the keyspace considerably. In that case it would definitely be security by obscurity, read: rather insecure.
编辑:在阅读丹尼斯轩尼诗的答案后,我必须修改答案。如果GUID确实以可解密的形式包含此信息(特别是mac地址),则攻击者可以大大减少密钥空间。在那种情况下,肯定是默默无闻的安全性,阅读:相当不安全。
And of course MusiGenesis is right: there are lots of tools that generate (pseudo) random passwords. My recommendation is to stick with one of those.
当然,MusiGenesis是对的:有很多工具可以生成(伪)随机密码。我的建议是坚持其中一个。
#2
11
Actually, using a GUID as a password is not a good idea (compared to coming up with a truly random password of equivalent length). Although it appears long, it's actually only 16 bytes which typically includes the user's MAC address, the date/time and a smallish random element. If a hacker can determine the users MAC address, it's relatively straightforward to guess possible GUID's that he would generate.
实际上,使用GUID作为密码并不是一个好主意(与提出一个等效长度的真正随机密码相比)。虽然看起来很长,但它实际上只有16个字节,通常包括用户的MAC地址,日期/时间和一个小的随机元素。如果黑客可以确定用户的MAC地址,那么猜测他将生成的可能的GUID是相对简单的。
#3
10
If one can observe the GUID being sent (e.g. via HTTP Auth), then it's irrelevant how guessable it is.
如果可以观察到正在发送的GUID(例如,通过HTTP Auth),那么它是多么可猜测是无关紧要的。
Some sites, like Flickr, employ an API key and a secret key. The secret key is used to create a signature via MD5 hash. The server calculates the same signature using the secret key and does auth that way. The secret never needs to go over the network.
某些网站(如Flickr)使用API密钥和密钥。密钥用于通过MD5哈希创建签名。服务器使用密钥计算相同的签名,并以此方式进行身份验证。秘密永远不需要通过网络。
#4
6
GUID is to prevent accidental collisions, not intentional ones. In other words, you are unlikely to guess a GUID, but it is not necessarily hard to find out if you really want to.
GUID是为了防止意外碰撞,而不是故意碰撞。换句话说,你不太可能猜出一个GUID,但不一定很难找出你是否真的想要。
#5
2
At first I was ready to give an unqualified yes, but it got me thinking about whether that meant that ALL password based authentication is security by obscurity. In the strictest sense I suppose it is, in a way.
起初我准备给出一个不合格的是,但它让我想到这是否意味着所有基于密码的身份验证都是默默无闻的安全性。从最严格的意义上来说,我认为它在某种程度上。
However, assuming you have users logging in with passwords and you aren't posting that GUID anywhere, I think the risks are outweighed by the less secure passwords the users have, or even the sysadmin password.
但是,假设您有用户使用密码登录并且您没有在任何地方发布该GUID,我认为用户拥有的安全性较低的密码甚至是sysadmin密码都会超过风险。
If you had said the URL to an admin page that wasn't otherwise protected included a hard coded GUID, then the answer would be a definite yes.
如果你说过一个没有受到其他保护的管理页面的URL包含一个硬编码的GUID,那么答案肯定是肯定的。
#6
1
I agree with most other people that it is better than a weak password but it would be preferable to use something stronger like a certificate exchange that is meant for this sort of authentication (if the device supports it).
我同意大多数其他人的看法,它比弱密码更好,但最好使用更强大的东西,如用于此类身份验证的证书交换(如果设备支持它)。
I would also ensure that you do some sort of mutual authentication (i.e. have the device verify the servers SSL certificate to ensure it is the one you expect). It would be easy enough of me to grab the device, plug it into my system, and read the GUID off of it then replay that back to the target system.
我还要确保您进行某种相互身份验证(即让设备验证服务器SSL证书以确保它是您期望的那个)。我很容易抓住设备,将其插入我的系统,并从中读取GUID,然后将其重播回目标系统。
#7
1
In general, you introduce security vulnerabilities if you embed the key in your device, or if you transmit the key during authentication. It doesn't matter whether they key is a GUID or a password, as the only cryptographic difference is in their length and randomness. In either case, an attacker can either scan your product's memory or eavesdrop on the authentication process.
通常,如果将密钥嵌入设备中,或者在身份验证期间传输密钥,则会引入安全漏洞。它们的密钥是GUID还是密码并不重要,因为唯一的密码差异在于它们的长度和随机性。在任何一种情况下,攻击者都可以扫描产品的内存或窃听身份验证过程。
You can mitigate this in several ways, each of which ultimately boils down to increasing the obscurity (or level of protection) of the key:
您可以通过多种方式缓解这种情况,每种方式最终都归结为增加密钥的默默无闻(或保护级别):
-
Encrypt the key before you store it. Of course, now you need to store that encryption key, but you've introduced a level of indirection.
在存储密钥之前加密密钥。当然,现在您需要存储该加密密钥,但您已经引入了一个间接级别。
-
Calculate the key, rather than storing it. Now an attacker must reverse-engineer your algorithm, rather than simply searching for a key.
计算密钥,而不是存储密钥。现在,攻击者必须对您的算法进行逆向工程,而不是简单地搜索密钥。
-
Transmit a hash of the key during authentication, rather than the key itself, as others have suggested, or use challenge-response authentication. Both of these methods prevent the key from being transmitted in plaintext. SSL will also accomplish this, but then you're depending on the user to maintain a proper implementation; you've lost control over the security.
在身份验证期间传输密钥的哈希值,而不是像其他人建议的那样传输密钥本身,或者使用质询 - 响应身份验证。这两种方法都阻止密钥以明文传输。 SSL也将实现这一目标,但是您依赖于用户来维护正确的实现;你失去了对安全的控制。
As always, whenever you're addressing security, you need to consider various tradeoffs. What is the likelihood of an attack? What is the risk if an attack is successful? What is the cost of security in terms of development, support, and usability?
与往常一样,无论何时解决安全问题,都需要考虑各种权衡。攻击的可能性有多大?攻击成功的风险是什么?在开发,支持和可用性方面的安全成本是多少?
A good solution is usually a compromise that addresses each of these factors satisfactorily. Good luck!
一个好的解决方案通常是妥协,令人满意地解决这些因素中的每一个。祝好运!
#8
0
It's better than using "password" as the password, at least.
它至少比使用“密码”作为密码要好。
I don't think a GUID would be considered a strong password, and there are lots of strong password generators out there that you could use just as easily as Guid.NewGuid().
我不认为GUID会被认为是一个强密码,并且有许多强大的密码生成器可以像Guid.NewGuid()一样轻松使用。
#9
0
It really depends on what you want to do. Using a GUID as password is not in itself security through obscurity (but beware the fact that a GUID contains many guessable bits out of the 128 total: there is a timestamp, some include the MAC address of the machine that generated it, etc.) but the real problem is how you will store and communicate that password to the server.
这真的取决于你想做什么。使用GUID作为密码本身并不是通过默默无闻的安全性(但要注意GUID在128个总数中包含许多可猜测位的事实:有一个时间戳,一些包括生成它的机器的MAC地址等)但真正的问题是如何存储密码并将其传递给服务器。
If the password is stored on a server-side script that is never shown to the end user, there is not much risk. If the password is embedded in some application that the user downloads to its own machine, then you will have to obfuscate the password in the application, and there is no way to do that securely. By running a debugger, a user will always be able to access the password.
如果密码存储在从未向最终用户显示的服务器端脚本中,则风险不大。如果密码嵌入在用户下载到自己的计算机的某个应用程序中,那么您将不得不在应用程序中模糊密码,并且无法安全地执行此操作。通过运行调试器,用户将始终能够访问密码。
#10
0
Sure it is security by obscurity. But is this bad? Any "strong" password is security by obscurity. You count on the authentication system to be secure, but in the end if your password is easy to guess then it doesn't matter how good the authentication system is. So you make a "strong" and "obscure" password to make it hard to guess.
当然,默默无闻是安全。但这是不是很糟糕?任何“强大”的密码都是默默无闻的安全性。您指望身份验证系统是安全的,但最后如果您的密码很容易被猜到,那么身份验证系统的好坏并不重要。因此,您制作一个“强大”和“模糊”的密码,以使其难以猜测。
#11
0
It's only security through obscurity to the extent that that's what passwords are. Probably the primary problem with using a GUID as a password is that only letters and numbers are used. However, a GUID is pretty long compared to most passwords. No password is secure to an exhaustive search; that's pretty obvious. Simply because a GUID may or may not have some basis on some sort of timestamp or perhaps a MAC address is somewhat irrelevant.
通过默默无闻只是安全,这就是密码的含义。使用GUID作为密码的主要问题可能是只使用字母和数字。但是,与大多数密码相比,GUID相当长。没有密码可以进行详尽的搜索;这很明显。仅仅因为GUID可能会或可能不会在某种时间戳或某个MAC地址上有某些基础,这有点无关紧要。
The difference in probability of guessing it and something else is pretty minimal. Some GUIDs might be "easier" (read: quicker) to break then others. Longer is better. However, more diversity in the alphabet is also better. But again, exhaustive search reveals all.
猜测它和其他东西的概率差异非常小。一些GUID可能“更容易”(阅读:更快)以打破其他人。越长越好。但是,字母表中的多样性也更好。但同样,详尽的搜索揭示了所有。
#12
0
I recommend against using a GUID as a password (except maybe as an initial one to be changed later). Any password that has to be written down to be remembered is
inherently
unsafe. It will get written down.
我建议不要使用GUID作为密码(除非可能是以后要更改的初始密码)。任何必须记下来记住的密码本质上都是不安全的。它会写下来。
Edit: "inherently" is inaccurate. see conversation in comments
编辑:“天生”是不准确的。在评论中看到对话
#1
13
In my opinion, the answer is no.
在我看来,答案是否定的。
If you set a password to be a newly created GUID, then it is a rather safe password: more than 8 charcters, contains numbers, letters ans special characters, etc.
如果您将密码设置为新创建的GUID,则它是一个相当安全的密码:超过8个字符,包含数字,字母和特殊字符等。
Of course, in a GUID the position of '{', '}' and '-' are known, as well as the fact that all letters are in uppercase. So as long as nobody knows that you use a GUID, the password is harder to crack. Once the attacker knows that he is seeking a GUID, the effort needed for a brute force attack reduces. From that point of view, it is security by obscurity.
当然,在GUID中,'{','}'和' - '的位置是已知的,以及所有字母都是大写的。因此,只要没有人知道您使用GUID,密码就更难破解。一旦攻击者知道他正在寻找GUID,蛮力攻击所需的努力就会减少。从这个角度来看,它是默默无闻的安全。
Still, consider this GUID: {91626979-FB5C-439A-BBA3-7715ED647504} If you assume the attacker knows the position of the special characters, his problem is reduced to finding the string 91626979FB5C439ABBA37715ED647504. Brute forcing a 32 characters password? It will only happen in your lifetime, if someone invents a working quantum computer.
不过,请考虑以下GUID:{91626979-FB5C-439A-BBA3-7715ED647504}如果您认为攻击者知道特殊字符的位置,则他的问题将减少为找到字符串91626979FB5C439ABBA37715ED647504。暴力迫使32个字符的密码?它只会在你的一生中发生,如果有人发明了一台有效的量子计算机。
This is security by using a very, very long password, not by obscurity.
这是安全性,使用非常非常长的密码,而不是默默无闻。
EDIT: After reading the answer of Denis Hennessy, I have to revise answer. If the GUID really contains this info (specifically the mac address) in a decryptable form, an attacker can reduce the keyspace considerably. In that case it would definitely be security by obscurity, read: rather insecure.
编辑:在阅读丹尼斯轩尼诗的答案后,我必须修改答案。如果GUID确实以可解密的形式包含此信息(特别是mac地址),则攻击者可以大大减少密钥空间。在那种情况下,肯定是默默无闻的安全性,阅读:相当不安全。
And of course MusiGenesis is right: there are lots of tools that generate (pseudo) random passwords. My recommendation is to stick with one of those.
当然,MusiGenesis是对的:有很多工具可以生成(伪)随机密码。我的建议是坚持其中一个。
#2
11
Actually, using a GUID as a password is not a good idea (compared to coming up with a truly random password of equivalent length). Although it appears long, it's actually only 16 bytes which typically includes the user's MAC address, the date/time and a smallish random element. If a hacker can determine the users MAC address, it's relatively straightforward to guess possible GUID's that he would generate.
实际上,使用GUID作为密码并不是一个好主意(与提出一个等效长度的真正随机密码相比)。虽然看起来很长,但它实际上只有16个字节,通常包括用户的MAC地址,日期/时间和一个小的随机元素。如果黑客可以确定用户的MAC地址,那么猜测他将生成的可能的GUID是相对简单的。
#3
10
If one can observe the GUID being sent (e.g. via HTTP Auth), then it's irrelevant how guessable it is.
如果可以观察到正在发送的GUID(例如,通过HTTP Auth),那么它是多么可猜测是无关紧要的。
Some sites, like Flickr, employ an API key and a secret key. The secret key is used to create a signature via MD5 hash. The server calculates the same signature using the secret key and does auth that way. The secret never needs to go over the network.
某些网站(如Flickr)使用API密钥和密钥。密钥用于通过MD5哈希创建签名。服务器使用密钥计算相同的签名,并以此方式进行身份验证。秘密永远不需要通过网络。
#4
6
GUID is to prevent accidental collisions, not intentional ones. In other words, you are unlikely to guess a GUID, but it is not necessarily hard to find out if you really want to.
GUID是为了防止意外碰撞,而不是故意碰撞。换句话说,你不太可能猜出一个GUID,但不一定很难找出你是否真的想要。
#5
2
At first I was ready to give an unqualified yes, but it got me thinking about whether that meant that ALL password based authentication is security by obscurity. In the strictest sense I suppose it is, in a way.
起初我准备给出一个不合格的是,但它让我想到这是否意味着所有基于密码的身份验证都是默默无闻的安全性。从最严格的意义上来说,我认为它在某种程度上。
However, assuming you have users logging in with passwords and you aren't posting that GUID anywhere, I think the risks are outweighed by the less secure passwords the users have, or even the sysadmin password.
但是,假设您有用户使用密码登录并且您没有在任何地方发布该GUID,我认为用户拥有的安全性较低的密码甚至是sysadmin密码都会超过风险。
If you had said the URL to an admin page that wasn't otherwise protected included a hard coded GUID, then the answer would be a definite yes.
如果你说过一个没有受到其他保护的管理页面的URL包含一个硬编码的GUID,那么答案肯定是肯定的。
#6
1
I agree with most other people that it is better than a weak password but it would be preferable to use something stronger like a certificate exchange that is meant for this sort of authentication (if the device supports it).
我同意大多数其他人的看法,它比弱密码更好,但最好使用更强大的东西,如用于此类身份验证的证书交换(如果设备支持它)。
I would also ensure that you do some sort of mutual authentication (i.e. have the device verify the servers SSL certificate to ensure it is the one you expect). It would be easy enough of me to grab the device, plug it into my system, and read the GUID off of it then replay that back to the target system.
我还要确保您进行某种相互身份验证(即让设备验证服务器SSL证书以确保它是您期望的那个)。我很容易抓住设备,将其插入我的系统,并从中读取GUID,然后将其重播回目标系统。
#7
1
In general, you introduce security vulnerabilities if you embed the key in your device, or if you transmit the key during authentication. It doesn't matter whether they key is a GUID or a password, as the only cryptographic difference is in their length and randomness. In either case, an attacker can either scan your product's memory or eavesdrop on the authentication process.
通常,如果将密钥嵌入设备中,或者在身份验证期间传输密钥,则会引入安全漏洞。它们的密钥是GUID还是密码并不重要,因为唯一的密码差异在于它们的长度和随机性。在任何一种情况下,攻击者都可以扫描产品的内存或窃听身份验证过程。
You can mitigate this in several ways, each of which ultimately boils down to increasing the obscurity (or level of protection) of the key:
您可以通过多种方式缓解这种情况,每种方式最终都归结为增加密钥的默默无闻(或保护级别):
-
Encrypt the key before you store it. Of course, now you need to store that encryption key, but you've introduced a level of indirection.
在存储密钥之前加密密钥。当然,现在您需要存储该加密密钥,但您已经引入了一个间接级别。
-
Calculate the key, rather than storing it. Now an attacker must reverse-engineer your algorithm, rather than simply searching for a key.
计算密钥,而不是存储密钥。现在,攻击者必须对您的算法进行逆向工程,而不是简单地搜索密钥。
-
Transmit a hash of the key during authentication, rather than the key itself, as others have suggested, or use challenge-response authentication. Both of these methods prevent the key from being transmitted in plaintext. SSL will also accomplish this, but then you're depending on the user to maintain a proper implementation; you've lost control over the security.
在身份验证期间传输密钥的哈希值,而不是像其他人建议的那样传输密钥本身,或者使用质询 - 响应身份验证。这两种方法都阻止密钥以明文传输。 SSL也将实现这一目标,但是您依赖于用户来维护正确的实现;你失去了对安全的控制。
As always, whenever you're addressing security, you need to consider various tradeoffs. What is the likelihood of an attack? What is the risk if an attack is successful? What is the cost of security in terms of development, support, and usability?
与往常一样,无论何时解决安全问题,都需要考虑各种权衡。攻击的可能性有多大?攻击成功的风险是什么?在开发,支持和可用性方面的安全成本是多少?
A good solution is usually a compromise that addresses each of these factors satisfactorily. Good luck!
一个好的解决方案通常是妥协,令人满意地解决这些因素中的每一个。祝好运!
#8
0
It's better than using "password" as the password, at least.
它至少比使用“密码”作为密码要好。
I don't think a GUID would be considered a strong password, and there are lots of strong password generators out there that you could use just as easily as Guid.NewGuid().
我不认为GUID会被认为是一个强密码,并且有许多强大的密码生成器可以像Guid.NewGuid()一样轻松使用。
#9
0
It really depends on what you want to do. Using a GUID as password is not in itself security through obscurity (but beware the fact that a GUID contains many guessable bits out of the 128 total: there is a timestamp, some include the MAC address of the machine that generated it, etc.) but the real problem is how you will store and communicate that password to the server.
这真的取决于你想做什么。使用GUID作为密码本身并不是通过默默无闻的安全性(但要注意GUID在128个总数中包含许多可猜测位的事实:有一个时间戳,一些包括生成它的机器的MAC地址等)但真正的问题是如何存储密码并将其传递给服务器。
If the password is stored on a server-side script that is never shown to the end user, there is not much risk. If the password is embedded in some application that the user downloads to its own machine, then you will have to obfuscate the password in the application, and there is no way to do that securely. By running a debugger, a user will always be able to access the password.
如果密码存储在从未向最终用户显示的服务器端脚本中,则风险不大。如果密码嵌入在用户下载到自己的计算机的某个应用程序中,那么您将不得不在应用程序中模糊密码,并且无法安全地执行此操作。通过运行调试器,用户将始终能够访问密码。
#10
0
Sure it is security by obscurity. But is this bad? Any "strong" password is security by obscurity. You count on the authentication system to be secure, but in the end if your password is easy to guess then it doesn't matter how good the authentication system is. So you make a "strong" and "obscure" password to make it hard to guess.
当然,默默无闻是安全。但这是不是很糟糕?任何“强大”的密码都是默默无闻的安全性。您指望身份验证系统是安全的,但最后如果您的密码很容易被猜到,那么身份验证系统的好坏并不重要。因此,您制作一个“强大”和“模糊”的密码,以使其难以猜测。
#11
0
It's only security through obscurity to the extent that that's what passwords are. Probably the primary problem with using a GUID as a password is that only letters and numbers are used. However, a GUID is pretty long compared to most passwords. No password is secure to an exhaustive search; that's pretty obvious. Simply because a GUID may or may not have some basis on some sort of timestamp or perhaps a MAC address is somewhat irrelevant.
通过默默无闻只是安全,这就是密码的含义。使用GUID作为密码的主要问题可能是只使用字母和数字。但是,与大多数密码相比,GUID相当长。没有密码可以进行详尽的搜索;这很明显。仅仅因为GUID可能会或可能不会在某种时间戳或某个MAC地址上有某些基础,这有点无关紧要。
The difference in probability of guessing it and something else is pretty minimal. Some GUIDs might be "easier" (read: quicker) to break then others. Longer is better. However, more diversity in the alphabet is also better. But again, exhaustive search reveals all.
猜测它和其他东西的概率差异非常小。一些GUID可能“更容易”(阅读:更快)以打破其他人。越长越好。但是,字母表中的多样性也更好。但同样,详尽的搜索揭示了所有。
#12
0
I recommend against using a GUID as a password (except maybe as an initial one to be changed later). Any password that has to be written down to be remembered is
inherently
unsafe. It will get written down.
我建议不要使用GUID作为密码(除非可能是以后要更改的初始密码)。任何必须记下来记住的密码本质上都是不安全的。它会写下来。
Edit: "inherently" is inaccurate. see conversation in comments
编辑:“天生”是不准确的。在评论中看到对话