在 url 中隐藏真实的数据库对象 ID [英] Hiding true database object ID in url's

查看:25
本文介绍了在 url 中隐藏真实的数据库对象 ID的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

出于安全目的,在 URL 中隐藏真实数据库对象 ID 的有用解决方案是什么?我发现其中一种解决方案是:

1) 使用

人们应该做什么

说明

通常,人们想要看起来随机的 URL.这不允许您加密然后认证 您希望混淆的数据库记录 ID.这样做需要至少 32 个字节的 URL 长度(对于 HMAC-SHA256),当以 base64 编码时为 44 个字符.

一个更简单的策略是生成一个随机字符串(请参阅 random_compat 以了解 random_bytes()random_int() 用于生成这些字符串)并引用该列.

此外,哈希被简单的密码分析破坏.他们的结论是:

<块引用>

我所描述的攻击明显优于蛮力攻击,因此从密码学的角度来看,该算法被认为已被破解,恢复salt很容易;使攻击者可以在任一方向运行编码并使理想散列函数的属性 2 无效.

不要依赖它.

What would be useful solutions for hiding true database object ID in URL for security purposes? I found that one of the solutions would be:

1) Using hashids open source project

2) Using something like same old md5 on creation of the object to generate hash and store it in database, then use it in url's and querying by them, but the drawback is that querying by auto-incremented primary keys (IDs) is faster than hashes. So I believe the possibility to hash/unhash would be better?

Also as I'm on Symfony, are there maybe bundles that I could not find or built in functionalities that would help?

Please tell me what you found useful based on your experiences.

解决方案

This question has been asked a lot, with different word choice (which makes it difficult to say, "Just search for it!"). This fact prompted a blog post titled, The Comprehensive Guide to URL Parameter Encryption in PHP .

What People Want To Do Here

What People Should Do Instead

Explanation

Typically, people want short random-looking URLs. This doesn't allow you much room to encrypt then authenticate the database record ID you wish to obfuscate. Doing so would require a minimum URL length of 32 bytes (for HMAC-SHA256), which is 44 characters when encoded in base64.

A simpler strategy is to generate a random string (see random_compat for a PHP5 implementation of random_bytes() and random_int() for generating these strings) and reference that column instead.

Also, hashids are broken by simple cryptanalysis. Their conclusion states:

The attack I have described is significantly better than a brute force attack, so from a cryptographic stand point the algorithm is considered to be broken, it is quite easy to recover the salt; making it possible for an attacker to run the encoding in either direction and invalidates property 2 for an ideal hash function.

Don't rely on it.

这篇关于在 url 中隐藏真实的数据库对象 ID的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆