Questions tagged «security»

我有一个.net应用程序，该应用程序使用Windows身份验证连接到SQL Server。 我们无法在应用程序中使用SQL Server身份验证。我们的项目中有很多Active Directory用户。因此，我们必须为SQL Server中的每个Active Directory用户创建一个单独的登录帐户，而不是为每个AD用户创建一个单独的登录帐户，是否可以使用SQL Server中的Active Directory用户组？

108 sql-server  sql-server-2008  security  authentication 

有什么方法可以从IIS7中删除“服务器”响应标头？有一些文章显示，使用HttpModules可以实现相同的目的。如果我们没有服务器的管理权限，这将很有帮助。我也不想写ISAPI过滤器。 我具有服务器的管理员权限。所以我不想做以上的事情。所以，请帮助我做同样的事情。

107 security  iis-7  header  response 

已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 有一个名为PokerPirate的新的开源扑克机器人。我对Web应用程序可以检测/阻止/击败扑克机器人的任何创新方式感兴趣。（这纯粹是学术性的讨论，本着与《 PokerPirate》写作的精神。）

107 security  artificial-intelligence  poker 

鲍勃使用Web应用程序来实现目标。和： 他的浏览器处于节食状态，因此不支持cookie。 Web应用程序是一种流行的应用程序，它在给定的时刻可以与许多用户打交道-它必须很好地扩展。只要保持会话会限制同时连接的数量，并且当然会带来不可忽略的性能损失，我们可能希望拥有一个无会话系统：) 一些重要的注意事项： 我们确实具有传输安全性（HTTPS及其最好的朋友）； 在幕后，Web应用程序代表当前用户（这些系统确实将Bob识别为用户之一）将很多操作委托给外部服务 -这意味着我们必须向他们转发Bob的凭据。 现在，我们如何对Bob进行身份验证（针对每个请求）？哪种方法可以实现这种情况？ 通过HTML表单隐藏字段使用凭据打网球 ... 球包含凭据（用户名和密码），两个球拍分别是浏览器和Web应用程序。换句话说，我们可以通过表单字段而不是通过cookie来回传输数据。在每个Web请求中，浏览器都会发布凭据。但是，对于单页应用程序，这看起来像是在橡胶墙上打壁球，而不是打网球，因为包含凭据的Web表单可能会在整个页面生命周期中保持有效 （并且服务器将配置为不提供凭据）。 将用户名和密码存储在页面的上下文中-JavaScript变量等。此处需要单页，恕我直言。 基于加密令牌的身份验证。在这种情况下，登录操作将导致生成加密的安全令牌（用户名+密码+其他内容）。该令牌将被发还给客户端，并且即将到来的请求将带有令牌。这有意义吗？我们已经有了HTTPS ... 其他... 不得已：不要这样做，将凭据存储在会话中！会议很好。有或没有cookie。 关于上述任何想法，您是否会想到任何Web /安全性问题？例如， 超时 -我们可以保留一个timestamp以及凭据（时间戳= Bob输入凭据的时间）。例如，当NOW-timestamp> threshold时，我们可能会拒绝该请求。 跨站点脚本保护-不应有任何不同，对吗？ 非常感谢您抽出宝贵的时间阅读本文：）

107 security  authentication  session-cookies  stateless  cookieless 

我想加密一个二进制文件。我的目标是防止任何人读取没有密码的文件。 具有相同密钥长度的AES或Blowfish是哪种更好的解决方案？我们可以假设攻击者拥有大量破解文件的资源（软件，知识，金钱）。

106 security  encryption  aes  blowfish 

我正在制作Windows应用程序，您需要先登录。 帐户详细信息包括用户名和密码，它们需要保存在本地。 这只是安全问题，因此使用同一台计算机的其他人看不到每个人的个人数据。 保存此数据的最佳/最安全方法是什么？ 我不想使用数据库，所以我尝试了一些与资源文件有关的事情。 但是，由于我对此很陌生，因此我不确定自己在做什么以及应该在哪里寻找解决方案。

106 c#  security  local 

我正在写一个应该在某种程度上安全的shell脚本，即不要通过命令的参数传递安全数据，最好不要使用临时文件。如何将变量传递给命令的标准输入？或者，如果不可能，如何正确使用临时文件执行此类任务？

105 security  bash  stdin 

我正在尝试使用可以通过Google Authenticator应用程序生成的一次性密码。 Google身份验证器的功能 基本上，Google身份验证器实现两种类型的密码： HOTP-基于HMAC的一次性密码，这意味着密码会在每次呼叫时更改，以符合RFC4226的要求，并且 TOTP-基于时间的一次性密码，每30秒更改一次（据我所知）。 Google身份验证器也可以在此处作为开源使用：code.google.com/p/google-authenticator 当前代码 我一直在寻找用于生成HOTP和TOTP密码的现有解决方案，但没有找到太多。我拥有的代码是负责生成HOTP的以下代码段： import hmac, base64, struct, hashlib, time def get_token(secret, digest_mode=hashlib.sha1, intervals_no=None): if intervals_no == None: intervals_no = int(time.time()) // 30 key = base64.b32decode(secret) msg = struct.pack(">Q", intervals_no) h = hmac.new(key, msg, digest_mode).digest() o = ord(h[19]) & 15 h = (struct.unpack(">I", h[o:o+4])[0] & …

104 python  security  authentication  one-time-password  google-authenticator 

此问题仅与防止跨站点请求伪造攻击有关。 具体来说，它是：通过Origin标头（CORS）进行的保护是否与通过CSRF令牌进行的保护一样好？ 例： 爱丽丝使用她的浏览器（使用cookie）登录到“ https://example.com ”。我认为她使用的是现代浏览器。 爱丽丝访问“ https://evil.com ”，evil.com的客户端代码对“ https://example.com ” 执行某种请求（经典CSRF场景）。 所以： 如果我们不检查Origin头（服务器端），也没有CSRF令牌，则我们有一个CSRF安全漏洞。 如果我们检查CSRF令牌，我们是安全的（但这有点乏味）。 如果我们确实检查了Origin标头，则应与使用CSRF令牌时一样阻止evil.com客户端代码的请求-除了，除非evil.com的代码可以某种方式设置Origin标头。 我知道，如果使用XHR（例如，跨域资源共享的安全性），这应该是不可能的，至少不能，如果我们相信W3C规范可以在所有现代浏览器中正确实现的话（可以吗？） 但是其他类型的请求呢？例如表单提交？加载脚本/ img / ...标签？还是页面可以用来（合法）创建请求的任何其他方式？还是一些已知的JS hack？ 注意：我不是在说 本机应用程序 操纵的浏览器 example.com页面上的跨站点脚本错误， ...

103 javascript  security  cors  csrf 

在我正在阅读的书中，写printf有一个参数（不带转换说明符）已被弃用。建议替代 printf("Hello World!"); 与 puts("Hello World!"); 要么 printf("%s", "Hello World!"); 有人可以告诉我为什么printf("Hello World!");错了吗？它写在书中，其中包含漏洞。这些漏洞是什么？

102 c  security  printf  format-specifiers  puts 

我正在为我维护的应用程序之一构建RESTful API。目前，我们正在寻找将需要更多控制访问和安全性的各种功能集成到其中。在研究如何保护API时，我发现了关于使用哪种形式的几种不同观点。我已经看到一些资源说HTTP-Auth是必经之路，而其他资源则更喜欢API密钥，甚至其他（包括我在SO上找到的问题）也都由OAuth宣誓。 然后，当然，喜欢API密钥的人会说OAuth是专为代表用户访问应用程序而设计的（据我所知，例如使用您的Facebook帐户登录非Facebook网站），而不是针对直接访问他们专门注册的网站上的资源的用户（例如访问Twitter服务器的官方Twitter客户端）。但是，对于OAuth的建议似乎甚至满足最基本的身份验证需求。 那么，我的问题是-假设所有操作都通过HTTPS完成，这三者之间的实际区别是什么？什么时候应该考虑一个？

101 security  api  restful-authentication 

我一直在研究PHP会话处理，发现session.gc_maxlifetime值1440秒。我一直想知道为什么标准值为1440，以及如何计算？此计算的依据是什么？ 保持会话多长时间才有意义？您会建议session.gc_maxlifetime的最小/最大值是多少？我说，价值越高，Web应用程序在会话劫持中就越容易受到攻击。

101 php  security  session 

我对的力量了解java.lang.reflect.AccessibleObject.setAccessible得越多，我对它能做的事情就越惊讶。这是根据我对问题的回答（使用反射更改静态最终File.separatorChar用于单元测试）改编而成的。 import java.lang.reflect.*; public class EverythingIsTrue { static void setFinalStatic(Field field, Object newValue) throws Exception { field.setAccessible(true); Field modifiersField = Field.class.getDeclaredField("modifiers"); modifiersField.setAccessible(true); modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); field.set(null, newValue); } public static void main(String args[]) throws Exception { setFinalStatic(Boolean.class.getField("FALSE"), true); System.out.format("Everything is %s", false); // "Everything is true" } } 您可以做真正令人发指的事情： …

100 java  security  reflection 

我意识到OAuth规范并未指定关于ConsumerKey，ConsumerSecret，AccessToken，RequestToken，TokenSecret或Verifier代码的来源的任何信息，但是我很好奇是否存在创建显着安全的令牌（尤其是Token /秘密组合）。 如我所见，有几种创建令牌的方法： 只需使用随机字节，存储在与使用者/用户关联的数据库中 散列一些特定于用户/消费者的数据，存储在与消费者/用户关联的数据库中 加密用户/消费者特定的数据 （1）的优点是数据库是看起来最安全的信息的唯一来源。攻击要比（2）或（3）难。 散列实际数据（2）将允许从可能已经已知的数据中重新生成令牌。可能不会真正为（1）提供任何优势，因为无论如何都需要存储/查找。比（1）占用更多的CPU资源。 加密真实数据（3）将允许解密以了解信息。与（1）和（2）相比，这将需要较少的存储空间并可能需要更少的查找，但是安全性也可能较低。 还有其他应考虑的方法/优点/缺点吗？ 编辑：另一个考虑是令牌中必须有某种随机值，因为必须存在过期和重新发行新令牌的能力，因此它不能仅由真实数据组成。 遵循问题： 是否有最小令牌长度才能显着地确保密码安全？据我了解，更长的令牌机密会创建更安全的签名。这种理解正确吗？ 从散列的角度来看，使用特定编码相对于其他编码是否有优势？例如，我看到很多使用十六进制编码的API（例如GUID字符串）。在OAuth签名算法中，令牌用作字符串。如果使用十六进制字符串，则可用的字符集将比使用Base64编码的字符集小得多（更可预测）。在我看来，对于两个长度相等的字符串，具有较大字符集的字符串将具有更好/更广泛的哈希分布。在我看来，这将提高安全性。这个假设正确吗？ OAuth规范在11.10秘密熵中提出了这个问题。

100 security  encryption  oauth  hash 

在工作中，我们有两种相互竞争的盐理论。我从事的产品使用诸如用户名或电话号码之类的东西来加杂凑。从本质上讲，每个用户都有所不同，但我们可以随时使用。其他产品会为每个用户随机生成一个盐，并在用户每次更改密码时都会更改它。然后将盐在数据库中加密。 我的问题是第二种方法是否真的必要？从纯粹的理论角度我可以理解，它比第一种方法更安全，但是从实用性角度来看又如何呢？现在要对用户进行身份验证，必须对salt进行加密，并将其应用于登录信息。 在考虑之后，我只是看不到这种方法真正的安全性收益。即使在攻击者知道如何快速确定每个帐户的含义的情况下，一个帐户一个帐户地更改盐，仍然使某人尝试强行使用哈希算法仍然非常困难。假设密码足够强。（显然，找到一组均为两位数字的密码，正确的哈希值要比找到正确的8位密码的哈希值容易得多）。我的逻辑是否正确，或者我缺少什么？ 编辑：好的，这就是为什么我认为加密盐真的没有意义。（让我知道自己是否走对了路）。 对于以下说明，我们假设密码始终为8个字符，salt为5，并且所有密码均由小写字母组成（这使数学更容易了）。 每个条目具有不同的盐值意味着我不能使用相同的彩虹表（实际上，如果我有一个足够大的表，我可以使用，但是暂时暂时忽略它）。从我的理解中，这是盐的真正关键，因为要破解每个帐户，我都必须重新发明轮子，以便为每个帐户说话。现在，如果我知道如何对密码应用正确的盐来生成哈希，我会这样做，因为盐实际上只是在扩展哈希短语的长度/复杂度。因此，我将减少生成“知道”密码（从13 ^ 26到8 ^ 26的密码）所需的可能组合的数量，因为我知道盐是什么。现在，它变得更容易，但仍然非常困难。 因此就加密了盐。如果我知道盐是加密的，那么我不会尝试对其进行解密（假设我知道它具有足够的加密级别）。我会忽略它。回到上一个示例，而不是试图弄清楚如何解密它，我只会生成一个更大的Rainbow表，其中包含13 ^ 26的所有密钥。不知道加盐肯定会使我慢下来，但是我认为这不会增加尝试先破解加盐加密的艰巨任务。这就是为什么我认为这不值得。有什么想法吗？ 以下是描述在暴力攻击下密码将保留多长时间的链接：http : //www.lockdown.co.uk/? pg=combi

99 security  encryption  hash  brute-force