Thông báo


Chia sẻ
Tùy chọn
Xem bài viết cuối
Offline admin  
#1 Đã gửi : 16/04/2015 lúc 08:47:12(UTC)

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 6,117
Viet Nam
Đến từ: Vietnam

Cảm ơn: 10 lần
Được cảm ơn: 2 lần trong 2 bài viết


Now in this tip I would like to share how to check encrypted password ?

Means once you stored your encrypted password in database now next step is to compare that particular password with your input password and return results accordingly.

The Syntax of the PWDCOMPARE is very simple

PWDCOMPARE(‘Password plain text’, ‘Password encrypted form’)

This function return 1 if plain text and hash value are matched else return o.

For example

Lets suppose we have created a table with 3 columns like UserId, username and password as shown below

Username VARCHAR(100), 
EncryptedPassword NVARCHAR(MAX))

Now suppose we have inserted 2 rows in to it wit encrypted password

INSERT INTO @tblLogin VALUES ('Indiandotnet',PWDENCRYPT(N'MyPassword')) 

Now, Suppose we have want to write a query which return rows from @tbllogin whose password is Test then it should return SQL Raaga for this

I have to write following query

SELECT * FROM @tblLogin WHERE PWDCOMPARE(N'Test',EncryptedPassword) = 1

For detail take a look of below snap


pwdencrypt: takes a varchar value as parameter and returns a varbin value that is the SQL Server password hash of the input value. I have seen people talking about the use of this function for hashing passwords when implementing custom application authentication. Do not use this! Starting with SQL Server 2005, you can use instead the HashBytes function, to implement any custom hashing scheme that you want. HashBytes provides you with direct access to several hashing algorithms, so there is no point in using pwdencrypt. In fact, I can't come up with any useful need for pwdencrypt and the only reason I included it here is to warn you against using it.

pwdcompare: takes two arguments - a varchar value that is a cleartext password and a varbin value that is a SQL Server password hash, and returns 1 if they match and 0 if they don't. There is a third optional parameter that can be set to 1 if the second parameter represents a pre-SQL Server 2000 password hash value. This third parameter will most likely be dropped in a future SQL Server version.

pwdcompare is useful if you are an administrator looking for accounts that have weak passwords. For example, to query for logins that have an empty password, the following queries can be used (first one will work on SQL Server 2000 and the second one uses the SQL Server 2005 new catalogs):

select name from sys.syslogins where pwdcompare('', password) = 1
select name from sys.sql_logins where pwdcompare('', password_hash) = 1

Obviously, these queries can be used to search for other weak passwords than empty ones. Does this constitute a threat against the strength of password hashes by allowing a TSQL brute-force attack? Not really, because such an approach would be very slow - it would be much more efficient to attempt such an attack using a compiled program, and even such approach would only have a good chance of success against a short or weak password. So, the pwdcompare function doesn't make an attacker's job easier. Other than helping administrators with checking for weak passwords, I can't think of another use for this function.

Ai đang xem chủ đề này?
OceanSpiders 2.0
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

| Cung cấp bởi YAF.NET | YAF.NET © 2003-2022, Yet Another Forum.NET
Thời gian xử lý trang này hết 0.272 giây.