h a l f b a k e r yJust add oughta.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
The password shadow file can be used relatively easily to check whether a particular string matches a particular user's password without being capable of producing that password. (See "cryptographic hashing" or "P vs NP problem".) Sysadmins get lazy and forget that shell command history might be retained
in plain text, but an absence of this logging is bad pratice in a shared administration environment. My personal favorite example is calling SQLPLUS against Oracle with a plain-text password on the command line. The proposed solution has one of two potential embodiments, but the core is the same: Use the /etc/shadow password hashes to exhaustively search the shell history for phrases with hash collisions. This search might include a predefined set of critical accounts on a system with a lot of users. As option 1, this search might be done the moment the shell history is committed to disk, or as option 2, it might be done as a cron job to simply reduce the exposure time, rotating the log after the scrub operation. (In the specific case of Oracle, a different hash source could be used, too.)
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
I assumed it was some kind of corporate greenwashing for petrochemical giants. |
|
| |
Option 3 would be to scan the log for known password parameter flags or positions and to selectively purge only those. Might work out of the box for 99% of standard software. |
|
| |
A small hardware addition and shell patch could be
made so that electric shocks of increasing severity
are applied to the operator when passwords are used
on the command line. |
|
| |
This is a pleasingly roundabout solution to an obscure but not non-existent problem. Well half-baked, Mr [thenerd]. [+] |
|
| |
What [pertinax] said. Although this type of
solution bothers me a little: When the computer
uses a fairly complex algorithm to identify things
to delete automatically, it can sometimes lead to
trouble. |
|
| |
One time I was writing a batch file that I wanted
to automatically download a file from the our
corporate intranet. I wanted it to run on any
windows machine with no extra software, so I
found some same code (VB script I think) that
would pull that file down. I put that sample code
into the script, saved it to disk, But when I tried
to run the batch file, it was gone. Luckily it was
still open in my text editor... It took me quite a
while to figure out that the virus scanner was
deleting the file, probably because some virus had
used the same sample code. I was able to get
around it by rearranging a few lines of code or
something, but then I decided to use a different
method since that behavior was rather virus-like
and I didn't want my scrip to stop working... |
|
| |
There must be some intended purpose for the shell
history or it wouldn't exist though right? couldn't
scrubbing this cause more problems? |
|
| |
//an absence of this logging is bad pratice in a shared
administration environment// |
|
| |
It's not any sort of logging at all, and treating it like it is
would be a very bad practice indeed. Two or more
simultaneously activated shells will not necessarily both log
their history, and even if they do it won't be in any
predictable order. A command's existence in the history file
tells you nothing about when it was run (even relative to
other commands in the file), and its non-existence is
absolutely no evidence that it wasn't. |
|
| |
//A small hardware addition and shell patch could be made
so that electric shocks of increasing severity are applied to
the operator when passwords are used on the command
line.// |
|
| |
Change your password to rm -rf*
You''d soon learn. |
|
| |