Major Problem - Does your client accept any password for existing AccountName?
Hey guys,
I found a serious problem in my server. I want to confirm if this is only happening to me or if it's happening to everyone.
When I create an account via SQL query I can login with any password as long as the AccountName exists. I tried logging in with existing AccountName and no password but it returns with "Please enter your password". I tried logging in with many combinations of passwords for the same account and they all allow me to log into the game.
Does this happen for you as well?
Here is the SQL query I'm using provided by leechclown in his tutorial.
Code:
USE [DNMembership]
GO
DECLARE @return_value int
EXEC @return_value = [dbo].[P_AddAccount]
@nvcAccountName = N'USERNAME',
@inyAccountLevelCode = 100,
@inyCharacterCreateLimit = 4,
@inyCharacterMaxCount = 4,
@dt2LastLoginDate = NULL,
@vchLastLoginIP = NULL,
@IntLastSessionID = NULL,
@vchJoinIP = NULL,
@inyPublisherCode = 4,
@inyGenderCode = NULL,
@DaTBirthDate = NULL,
@vchPassphrase = N'PASSWORT',
@inyNationalityCode = NULL,
@inyChannelPartnerCode = NULL
SELECT 'Return Value' = @return_value
GO
- - - Updated - - -
I just deleted all of my databases and restored them with the .bak files provided by someone on the forum. I'm still able to log into accounts with any password. For example..
I created this account:
AccountName: test
Password: test123
I can login with any password like 123test, bob, sdkfljasd, 94m8q3cura, etc. No matter what I enter in the password field of client I can login as long as I have the AccountName right. Can someone else please confirm this for me?
Re: Major Problem - Does your client accept any password for existing AccountName?
Yep..me too..
That's because the procedure didn't fill the password..
try to register with PublisherCode 0
It'll fill the password but still can't login..password always wrong..
I'm stuck on there right now..
Sent from my LT18i using Tapatalk
Re: Major Problem - Does your client accept any password for existing AccountName?
Quote:
Originally Posted by
Aku_ya_aku
Yep..me too..
That's because the procedure didn't fill the password..
try to register with PublisherCode 0
It'll fill the password but still can't login..password always wrong..
I'm stuck on there right now..
Sent from my LT18i using Tapatalk
That really sucks! I wonder how other private server moved past this. I have a really nice registration page created, but it's pretty much worthless until this is figured out. Do you know what the game client is reading the password as? Like does the it try to read password as varchar or binary? I noticed that when I changed the PublisherCode to 0 it changes the passwords to <binary data> in Passphrase column.
Anyone else have some knowledge of this they can share?
Re: Major Problem - Does your client accept any password for existing AccountName?
d1ey0u what release u use? adasmin or leech?
Re: Major Problem - Does your client accept any password for existing AccountName?
i have same problem , need fix please
Re: Major Problem - Does your client accept any password for existing AccountName?
in database i see have some md5 and sha1 but in varchar(12).try use in website register with md5
Re: Major Problem - Does your client accept any password for existing AccountName?
Quote:
Originally Posted by
megingjard
d1ey0u what release u use? adasmin or leech?
I'm using leechclown's files. I don't have a problem using md5 hash when storing into database. I tried that. I'm not sure what it is. When I use the md5 hash it stores in the database under passphrase column as <binary data>. When I use the SQL query it stores at NULL. I've tested multiple methods for the reg page, but like Aku_ya_aku said, we think it's related to the publishercode. When you use 0 it stores the password as <binary data>.
Please, anyone, if you can enlighten us please do. You'll be very impressed with this new registration page I've created! :D
Re: Major Problem - Does your client accept any password for existing AccountName?
Quote:
Originally Posted by
d1ey0u
I'm using leechclown's files. I don't have a problem using md5 hash when storing into database. I tried that. I'm not sure what it is. When I use the md5 hash it stores in the database under passphrase column as <binary data>. When I use the SQL query it stores at NULL. I've tested multiple methods for the reg page, but like Aku_ya_aku said, we think it's related to the publishercode. When you use 0 it stores the password as <binary data>.
Please, anyone, if you can enlighten us please do. You'll be very impressed with this new registration page I've created! :D
can share your registration page?
Re: Major Problem - Does your client accept any password for existing AccountName?
ok let`s see what have in database :) Here it is..
i hope you will share that register page if success
i think you can understand this..
ALTER PROCEDURE [dbo]. [P_AddAccount]
@ nvcAccountName nvarchar (50) - / / login account name
, @ InyAccountLevelCode tinyint - / / 0 = normal user , 10 = new ( Nexon ), 20 = Monitoring ( Nexon ), 30 = Master ( Nexon ), 99 = QA, 100 = developer
, @ InyCharacterCreateLimit tinyint - / / one day be capable of generating a character
, @ InyCharacterMaxCount tinyint - / / maximum number of characters that can hold
, @ Dt2LastLoginDate datetime2 (0) - / / last login date
, @ VchLastLoginIP varchar (15) = NULL - / / (optional) the IP address of last login
, @ IntLastSessionID int = NULL - / / (optional) last login session ID
, @ VchJoinIP varchar (15) = NULL - / / (optional) First , the IP address Join
, @ InyPublisherCode tinyint - / / 0 = studio , 1 = Nexon , Shanda 2 = , 3 = NHN Japan
, @ InyGenderCode tinyint = NULL - / / (optional) 1 = male , 2 = female
, @ DatBirthDate date = NULL - / / (optional) Date of Birth ( birth , but can be effective . )
, @ VchPassphrase varchar (12) = NULL - / / (optional) account password for in-house testing
, @ InyNationalityCode tinyint = NULL - / / country code. 95Hong Kong, 207 = Taiwan
, @ InyChannelPartnerCode tinyint = NULL - / / 1 = MSN (Japan). NULL if the publishers own account and enter a value.
, @ IntAccountID int = NULL OUTPUT - / / login account ID
so this is what i understand ..
IF @inyPublisherCode = 0 AND @vchPassphrase IS NOT NULL
UPDATE dbo.Accounts
SET Passphrase = dbo.FN_HashPassphrase(@vchPassphrase, @IntAccountID)
WHERE AccountID = @IntAccountID;
so here is some encryption begin..
in database have 2 way of encryption
let`s me show you something
if you use this
dbo.FN_HashPassphrase This For sha1
dbo.FN_HashPassphrase2 this for md5
so here some script in on dbo.FN_HashPassphrase
dnmembership>Programmability>Functions>dbo.FN_HashPassphrase
ALTER FUNCTION [dbo].[FN_HashPassphrase](
@vchPassphrase varchar(12), @IntAccountID int
)
RETURNS binary(20)
AS
BEGIN
RETURN (
HASHBYTES('SHA1', '818719D11B0B41CA80C22F5D9901E92B' + STR @IntAccountID, 10) + @vchPassphrase)
);
END
and here for dbo.FN_HashPassphrase2
Location Of Function :
dnmembership>Programmability>Functions>dbo.FN_HashPassphrase2
ALTER FUNCTION [dbo].[FN_HashPassphrase2](
@vchPassphrase varchar(12), @IntAccountID int
)
RETURNS binary(20)
AS
BEGIN
RETURN (
HASHBYTES('md5',@vchPassphrase)
);
END
ALTER FUNCTION [dbo].[FN_HashPassphrase2](
@vchPassphrase varchar(12), @IntAccountID int
)
RETURNS binary(20)
AS
BEGIN
RETURN (
HASHBYTES('md5',@vchPassphrase)
);
END
to create register page must understand encryption in database..so here it is..
alway we see that must be varchar(32) for md5 and sometime that is varchar(30)
but in this binary(20)
i hope you will success..
if we use this query
USE [DNMembership]
GO
DECLARE @return_value int
EXEC @return_value = [dbo].[P_AddAccount]
@nvcAccountName = N'Yourname',
@inyAccountLevelCode = 100,
@inyCharacterCreateLimit = 4,
@inyCharacterMaxCount = 4,
@dT2LastLoginDate = NULL,
@vchLastLoginIP = NULL,
@IntLastSessionID = NULL,
@vchJoinIP = NULL,
@inyPublisherCode = 4,
@inyGenderCode = NULL,
@DaTBirthDate = NULL,
@vchPassphrase = N'Here Maybe Some md5 Password with varchar 12 not 32 only way to get varchar 12 is using register page ..that you :D',
@inyNationalityCode = NULL,
@inyChannelPartnerCode = NULL
SELECT 'Return Value' = @return_value
GO
Re: Major Problem - Does your client accept any password for existing AccountName?
Re: Major Problem - Does your client accept any password for existing AccountName?
Quote:
Originally Posted by
megingjard
dnmembership>Programmability>Functions>dbo.FN_HashPassphrase
ALTER FUNCTION [dbo].[FN_HashPassphrase](
@vchPassphrase varchar(12), @IntAccountID int
)
RETURNS
binary(20)
AS
BEGIN
RETURN (
HASHBYTES('SHA1', '818719D11B0B41CA80C22F5D9901E92B' + STR @
IntAccountID, 10) + @vchPassphrase)
);
END
and here for dbo.FN_HashPassphrase2
Location Of Function :
dnmembership>Programmability>Functions>dbo.FN_HashPassphrase2
ALTER FUNCTION [dbo].[FN_HashPassphrase2](
@vchPassphrase varchar(12), @IntAccountID int
)
RETURNS
binary(20)
AS
BEGIN
RETURN (
HASHBYTES('md5',@vchPassphrase)
);
END
ALTER FUNCTION [dbo].[FN_HashPassphrase2](
@vchPassphrase varchar(12), @
IntAccountID int
)
RETURNS binary(20)
AS
BEGIN
RETURN (
HASHBYTES('md5',@vchPassphrase)
);
END
to create register page must understand encryption in database..so here it is..
alway we see that must be varchar(32) for md5 and sometime that is varchar(30)
but in this binary(20)
i hope you will success..
I'm not sure where you're getting this from. As you can see above, the text highlighted in purple are both accepting the textbox input for password as varchar(12) (this is what it's set to in my registration form). When the text is received as varchar(12) it is then converted into a hash, either md5 or sha1.
I've tested this method using both HashPassphrase & HashPassphrase2 with a publishercode of 0 so it stores other than NULL. I still get a password mismatch in client. It would be helpful if we knew what the client is checking the password as. For example, if the client accepts a varchar(12) password then converts it to md5 before it checks the database's Passphrase column, then we would use md5 hash during registration.
Whatever the case may be with the registration page, it really doesn't matter until we can figure out with the SQL query first. Because if using the query can use either md5 or sha1 and it still allows you to login with any password or you get password mismatch then the registration page will do the same since it's using the stored procedure P_AddAccount.
Re: Major Problem - Does your client accept any password for existing AccountName?
you right... this like dragonnest.exe dont have md5 funtion.are you already try change passphrase to varchar not to binary..?maybe client Indo version can read it..
before that can you try using this client
http://download2.nexon.net/Game/Drag...tSetupV347.exe
and using publishercode of 0
Re: Major Problem - Does your client accept any password for existing AccountName?
i think we can skip this password and just ask players to set a unique 2nd pass
Re: Major Problem - Does your client accept any password for existing AccountName?
any luck with making procedure work?
Re: Major Problem - Does your client accept any password for existing AccountName?
It has nothing to do with Databases.