Post reply

How to recover a SQL Server login password.

  • April 24, 2015 at 12:42 am

    #1793176

    Hi Geoff thanks for the nice article, I tried hashes from 2 different machines but I get skipping line: <hashes> (line length exception) for each row in my hashes.txt file. Is there something i am doing wrong. I tried hashes from a 2005 sp4 and 2008 r2 sp3 box. ? 🙂

    Hi Geoff I discovered what the mistake was -m 131 for SQL 2000 hashes and -m 132 for SQL 2005 and SQL2008 r2 hashes. Once again thanks for a short but very helpful article. Time to test my i7 cpu tonight...:w00t:

    Failure is an event not a person: Zig Ziglar

  • April 24, 2015 at 4:17 am

    #1793213

    Make sure you bring the horsepower. I ran Hashcat on a middling developer box with no GPU, and the estimate to solve was... 10 years.

  • April 24, 2015 at 6:13 am

    #1793231

    According to the --help output, -m 131 is for sql 2000. For sql 2008 use -m 132

  • April 24, 2015 at 7:16 am

    #1793249

    Great article and must know for for database professional.

  • April 24, 2015 at 7:35 am

    #1793257

    Better to just store the passwords in a password vault. 😉 By the time you crack it, the server will be decommissioned!

    I tried to crack a password that I know is a two dictionary words separated by a hyphen. It ran for a few hours and I interrupted it before it had finished. Maybe if I had tweaked the parameters a bit I could have had it finish sooner.

  • April 24, 2015 at 7:48 am

    #1793268

    Yes, it may not work if you use -m131. You will get hash length error. need to use -m132.

  • April 24, 2015 at 9:09 am

    #1793304

    *******

    hunter2

    It works!

  • April 24, 2015 at 12:01 pm

    #1793373

    Thanks for that, I was also getting the line length error message and it was the same problem: the -m 131 needed to be a -m 132

  • April 24, 2015 at 12:54 pm

    #1793392

    Great article. I'm trying to use this in a production environment and it's giving me a line length exception. The hash is 54 chars in length.

    Same here....132

  • April 24, 2015 at 1:57 pm

    #1793407

    Looks like we will need to monitor logins and login attempts, which is something rarely done. Does anyone track logins on their systems? Within a order of magnitude, how many are there in a day?

  • April 26, 2015 at 12:44 pm

    #1793537

    Here's a page that will help if you're getting the line length exception mentioned throughout this thread.

    https://hashcat.net/wiki/doku.php?id=example_hashes

    As noted by others, SQL 2005 and SQL 2008 require the -m parameter to be set to 132, not 131 as shown in the article. Of course, this is for hashcat 0.49 which may be newer than when this article was originally written back in 2013.

    Cheers,

    Kevin

  • April 27, 2015 at 7:06 am

    #1793645

    Thanks for the tip.

  • April 28, 2015 at 1:29 am

    #1793869

    Hi I am getting line length exception. Please help me how can i fix this....

    My cmd:

    hashcat-cli64.exe -a 3 --pw-min=2 --pw-max=12 -m 131 -p : -o "C:\Users\BaluM\Desktop\hashcat-0.49/SQL_passwords.txt" -n 2 "C:\Users\BaluM\Desktop\hashcat-0.49/Hashes.txt" -1 ?l?u?d?s ?1?1?1?1?1?1?1?1?1?1?1?1

    Error:

    Skipping line: 0x0100e8ad828763d96e4fbf45d2db223940dcca99b2ebfd03dec0 (line leng

    th exception)

    No hashes loaded

  • April 28, 2015 at 8:48 pm

    #1794166

    Well... that was a scary read, but thank you. Why would MS even make it possible to query the password hashes!? It should be an internal process completely hidden away. I see no benefit in sys.sql_logins retuning a password_hash column.

    Anything can be fixed

  • June 26, 2015 at 9:50 am

    #1808453

    Great post. Thanks very much.

    had to use -m 132 for my SQL 2005 box.

    Otherwise ran perfectly

Viewing 15 posts - 46 through 59 (of 59 total)

You must be logged in to reply to this topic. Login to reply