home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / hackers / 1735 < prev    next >
Encoding:
Text File  |  1992-11-22  |  1.8 KB  |  43 lines
  1. Newsgroups: alt.hackers
  2. Path: sparky!uunet!super!adamfox
  3. From: adamfox@super.super.org (Adam Fox)
  4. Subject: Re: cracking login?
  5. Message-ID: <1992Nov22.215621.8985@super.org>
  6. Keywords: cracking loign
  7. Sender: adamfox@super (Adam Fox)
  8. Nntp-Posting-Host: super
  9. Organization: Supercomputing Research Center, Bowie, MD  USA
  10. References:  <1eorh6INN684@dixie.cs.ubc.ca>
  11. Date: Sun, 22 Nov 1992 21:56:21 GMT
  12. Approved: of course, you foolish mortal
  13. Lines: 28
  14.  
  15. In article <1eorh6INN684@dixie.cs.ubc.ca>, hassan@cs.ubc.ca (Moustafa Hassan) writes:
  16. |> I've thought of a scheme for logging in as any user in a given file system.
  17. |> The only problem is that it's too easy.  I must be under some illusion.
  18. |> I'd appreciate it if someone pointed out the flaw in my algorithm:
  19. |> 
  20. |> 1.  Obtain the code for login.c.  I've done this.  I'm having some trouble
  21. |>     compiling it, because some constants are defined differently on my 
  22. |>     system.  I should be able to fix this within a month's work.
  23. |> 2.  Change the call to getpass to a function that reads in an arbitrary number
  24. |>     of characters up to the newline.  This is trivial.
  25. |> 3.  Remove the encryption step where the password is encrypted.
  26. |> 4.  Recompile.
  27. |> 5.  When executing login, give it (the publically available) user id and 
  28. |>     encrypted password of any user on the system, and you're in.
  29. |> 
  30. |> As I said, this scheme is too easy, and I refuse to believe that unix systems
  31. |> lack security to such a degree.  Would someone take the time to disillusion
  32. |> me?
  33.  
  34. I don't believe this will work because if I am not mistaken, the password
  35. is sent PLAINTEXT and is then encrypted on the remote host, then compared
  36. with the encrypted string in the password database.  Therefore, sending an 
  37. encrypted hash would not help as that hash would be hashed.
  38.  
  39. -- Adam Fox
  40. adamfox@super.org
  41.  
  42.  
  43.