iSeries (AS/400) 数据库文件：密码加密
我正在帮助完成一个项目，其中 iSeries 上的旧软件系统应用了全新的 .NET UI。一切进展顺利......除了......
为了允许用户登录并保持与现有软件安装的兼容性，我们需要弄清楚以前的供应商在不访问其源代码的情况下使用了什么加密/散列方法。
我有一个包含 ID 和密码列的文件。密码列似乎每条记录仅包含 16 个字符，均为二进制。
以前的供应商系统部分是用400上的原生绿屏编写的，部分是用Microsoft ASP.Net编写的。
什么类型的加密或哈希：
- 由 AS/400 或 iSeries 绿屏应用程序使用，
- 由 Microsoft .NET 应用程序使用，并且
- 无论输入长度如何，输出一致的 16 个二进制
字节非常感谢。谢谢！
I am helping with a project in which an old software system on an iSeries is having a brand new .NET UI applied to it. It's going well... except...
In order to allow users to login and maintain compatibility with the existing software installation, we need to figure out what encryption/hashing method the previous vendor was using without access to their source code.
I have a file with an ID and Password column. The password column appears to contains only 16 characters per record, all binary.
Part of the previous vendor system was written in native green screen on the 400, and part of it was written in Microsoft ASP.Net.
What type of encryption or hash would be:
- Used by an AS/400 or iSeries Green Screen app, and
- Used by a Microsoft .NET app, and
- Output a consistent 16 binary bytes, regardless of input length
Pointers much appreciated. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
i 有许多内置和第三方加密方案。最好的办法是找到供应商在其应用程序中使用的 API 或直接询问他们。一个设计良好的应用程序会将登录代码放在一个位置。
注意：我与足够多的供应商打过交道，知道我所说的就像要求你将埃菲尔铁塔向左移动 2 英寸。
There are many built-in and third party encryption schemes for the i. Your best bet is to find the API that the vendor uses in their applications or ask them directly. A well-designed application would have that log-in code in one spot.
Note: I have dealt with enough vendors to know that what I am saying is like asking you to move the Eiffel Tower 2 inches to the left.
第一个停靠点是旧系统的系统手册。之后联系供应商，并假设您支付了支持费用（您确实支付了支持费用，不是吗），让他们的技术支持人员回答您的问题。
如果这对你没有任何帮助，你就必须开始挖掘。 16 个字符是 128 位，因此您可能有某个东西的 128 位哈希值。最有可能的是 MD5，特别是如果原始代码的日期是从 1991 年到 1996 年左右。
接下来，您需要决定是否在对密码进行哈希处理之前向密码添加盐。在旧系统上创建两个具有不同用户名和相同密码的新用户帐户。说“用户1/密码”和“用户2/密码”。现在查看密码文件并找到两个新条目。如果两个哈希值相同，则没有使用盐，并且您可能有一个简单的密码哈希值。如果没有，则尝试用户名和密码的简单组合的 MD5 哈希：
user1password
密码user1
用户1:密码
密码：user1
等等。
如果其中之一有效，那么您已经解决了它。如果没有，那么你将花费很长时间来构建彩虹表和各种其他密码分析的东西。
如果达到了这一点，那么在您的网络上放置一个网络嗅探器可能会更容易，它会攻击旧系统，这样您就可以在用户密码被散列之前读取它们。为了获得额外的确定性，请在记录密码之前检查以其他方式返回的“您已正确登录”消息。他们可能会在错误的时间输入错误。
First port of call is the system manual for the old system. After that contact the supplier, and assuming you paid for support (you did pay for support, didn't you), get their technical support people to answer your question.
If that doesn't get you anywhere, you have to start digging. Sixteen characters is 128 bits, so you probably have a 128 bit hash of something. Most likely MD5, especially if the original code dates from about 1991 to 1996.
Next you need to decide if it is adding a salt to the password before hashing it. Create two new user accounts on the old system with different usernames and the same password. Say "user1/password" and "user2/password". Now look at the password file and locate the two new entries. If the two hashes are the same then no salt was used, and you probably have a simple hash of the password. If not then try the MD5 hash of simple combinations of the username and password:
user1password
passworduser1
user1:password
password:user1
etc.
If one of these works then you have solved it. If not then you are going to spend a very long time building Rainbow Tables and all sorts of other cryptanalytic stuff.
If it gets to that it might be easier to just put a network sniffer onto your network where it hits the old system so you can read your users' passwords before they get hashed. For additional certainty check for the "You logged in correctly" message going back the other way before you record the password. They might mistype it just at the wrong time.