blocks|key|1385981|text|OpenID地址不应该被加密，因为这是你的“开放id”，每个人都应该知道它的值。此外，URL需要是数据库中的索引，并且加密数据库中的索引总是有问题的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1385982|OAuth令牌/密码应该是保密的，如果您必须长期存储令牌，加密可能会提高安全性。在我们的OAuth消费者应用程序中，令牌/秘密只在会话中存储一小段时间，并且我们选择不对它们进行加密。我认为这已经足够安全了。如果有人可以偷看我们的会话存储，他们可能也有我们的加密密钥。|1385983|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

OpenID URL shouldn't be encrypted because this is your "open id" literally, everyone should know the value. Besides, the URL needs to be an index in the database and it's always problematic to encrypt the index in the database. 

OAuth token/secret should be secret and encryption may improve security if you have to store the token long term. In our OAuth consumer application, token/secret is only stored in session for a short while and we choose not to encrypt them. I think that's secure enough. If someone can peek into our session storage, they probably have our encryption key also.

blocks|key|1170822|text|显然，OAuth令牌和密码都应该安全地保存在您的数据库中，但您不能像存储密码那样使用单向加密来存储它们。原因是您需要令牌和密码才能对请求进行签名。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1170823|如果您运行的是OAuth服务器，也会出现这种情况，您仍然需要原始令牌/密码来验证请求。|1170824|如果您愿意，您仍然可以使用双向加密算法对它们进行加密，以提供安全性，以防您的数据库或数据库备份受到威胁。|1170825|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The OAuth Token and Secret should both obviously be kept safe in your database, but you can't store them using 1 way encryption the same way you would for a password. The reason being is that you need the token and secret to be able to sign the request.

This would also be the case if you are running an OAuth server, you still need the original token/secret to verify the request.

If you want to you could still encrypt them using a 2 way encryption algorithm such as AES to offer security in case your database or database backups get compromised.

blocks|key|1386162|text|首先，有一个已注册的应用程序，它包含consumer_key和consumer_secret。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1386163|当用户验证并“允许”您已注册的应用程序时，您将得到回报:一个被视为用户“密码”的access_token，它将只允许您的应用程序代表用户执行操作。|1386164|因此，如果用户没有用于完全访问的consumer_key和consumer_secret，那么从数据库中只获取用户的access_token就没有多大帮助。|1386165|服务提供商根据请求比较所有4个参数。在存储之前加密这4个参数，并在响应之前解密它们，这将是明智的。|1386166|这正是当您需要代表用户更新或更改用户的资源所有者时。要使用户在您的站点上保持登录状态，请使用会话。|1386167|entityMap^0|I|C|V|F|0|14|C|0|G|C|T|F|1M|C|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|14|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|15|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|O|$]]

First, there is a registered application that has <code>consumer_key</code> and <code>consumer_secret</code>.

When users authenticate and "allow" your registered application, you get back:
an <code>access_token</code> that is considered the user's "password" and would allow JUST YOUR application to act on the user's behalf.

So, getting just the user's <code>access_token</code> from your database won't help much if they don't also have the <code>consumer_key</code> and <code>consumer_secret</code> for complete access.

The service provider compares all 4 parameters on request. It would be smart to encrypt these 4 parameters before storage and decrypt them before response.

This is just when you need to update or make changes to the user's resource owner on behalf of a user. To keep a user logged-in on your site, use sessions.

blocks|key|1170927|text|是的，这些数据应该在数据库中以静态方式进行对称加密(比如，CBC模式下的AES-256+)。加密这些令牌的一种简单方法是使用SecureDB的加密即服务RESTful+API。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1170928|披露:我在SecureDB工作。|1170929|entityMap|0|LINK|mutability|MUTABLE|url|https://securedb.co/^0|1Q|8|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Yes, these should be symmetrically encrypted (say, AES-256 in CBC mode) at rest in a database. A simple way to encrypt these tokens is using <a href="https://securedb.co" rel="nofollow">SecureDB</a>'s Encryption as a Service RESTful APIs. 

Disclosure: I work at SecureDB.

I am creating a web app that will use OpenID logins and OAuth tokens with Youtube. I am currently storing the OpenID identity and OAuth token/token secret in plain text in the database.

Is it inappropriate to store these values as plain text? I could use a one-way encryption for the OpenID identifier but I don't know if that is necessary. For the OAuth tokens, I would need to use a two-way encryption as my app relies on getting the session token for some uses.

Is it necessary to encrypt the OpenID identity? Could someone use it to gain access to a user's account?

Securly Storing OpenID identifiers and OAuth tokens

对称加密

RESTful API

数据库

服务器

OAuth

我正在创建一个网络应用程序，将使用OpenID登录和OAuth令牌与Youtube。我目前在数据库中以纯文本形式存储OpenID身份和OAuth令牌/令牌秘密。将这些值存储为纯文本是否不合适？我可以对OpenID标识符使用单向加密，但我不知道是否有必要这样做。对于OAuth令牌，我需要使用双向加密，因为我的应用程序在某...

问安全存储OpenID标识符和OAuth令牌
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问安全存储OpenID标识符和OAuth令牌EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问安全存储OpenID标识符和OAuth令牌
EN