/boot, which (usually) contains the grub files (the has is stored in the grub menu config file) is USUALLY readable to all. Ubuntu/debian and friends usually store that as/boot/grub/menu.lst. The password hash is saved in the line "password --md5 HASHVALUEHERE" or, without hash, as "password PASSWORDVALUE" and the boot stanzas are proteced with "lock" if they require the password to be used.
Thanks for the link to the MD5 collision info. Indeed, it still works for passwords.
It's even better because exchange DOES have a retention system. File -> Archive. Hell theres ways for IT to force a retention policy down from group policy!
That I understand. But any user who can get into the system enough to read/boot can read that hash, and if they break it they could (probably) set init as anything they want, which could exploit a potential flaw on some kind of security scheme.
If I knew what said flaw in hypothetical scheme was, it wouldn't be so much of an issue. I'm just wondering if the hash itself is safe.
but that brings up another point... what stops someone from booting from something else and just editing the grub config to remove the password? Doesn't seem that there is any real way to secure a system on boot from local access.
The summary (did not read the article) states that there was no warning and good indications that accidental death was a possibility. They are after answers, not insights to his mindset.
Just mount the partition with a liveCD, edit/etc/shadow (or/etc/passwd if he's a moron, which I doubt) and put your own password hash in.
Of course if the drive is encrypted, you are most likely SOL.
Re:Started the download 20 minutes ago
on
Ubuntu 8.04 Released
·
· Score: -1, Flamebait
Thanks jerks. I had been running hardy off the archive for a week, and was just installing an apache/php/postgres stack when you all decided to crap up the archives.
He has a little key fob that generates a passphrase based on time and some hidden magic (RSA). The server has one too, with the same hidden magic. Hence, both you and the server will know it, nobody else will until you use it, but once used it's worthless.
Get an old-ass laptop with wireless (USB/PCMCIA/MiniPCI doesn't matter) and an ethernet port. Set up ip-forwarding, and stick it between the work laptop and the wireless access point. If your even more paranoid, tunnel the connection to the work laptop to somewhere else (ie, home) so that it is virtually impossible to discern where you actually connected the damn thing (latency being the only real way)
How will they know you didn't just plug it in the wall? The only drawback would be the space for the extra hardware, and looking like a tool while using.
He/She didn't give her/his domain, and presumably if it's never linked to, it will never get indexed. Google doesn't (does it?) randomly try URLs to find sites to index!
I'm not trying to prevent them from seeing sensitive, data, I want to prevent them from seeing any at all! I don't care what they are looking for, I don't want them in any of my business unless they have a warrant! Leaving holes like this are just asking for abuse - witness customs violating and stealing laptops at the border. Yes, I chose those words particularly.
Get your shit together and write your text with the citation at the same time. You don't write a paper for class, then a week after it's graded give the professor your bibliography, do you?
We are using the MS SQL enterprise manager in class (database security) and it bothers me that all this is going on and I really don't have much of a clue what it is doing. I recognize that I'm unusual in that I'd rather spend an assload of time doing it all myself with the documentation and know what is done.
Maybe it's just because I'm not your average bear... but (as a complete DB newbie) I had no trouble discovering and understanding the point of that "su postgres" step. I like the idea that the database is unusable until I say otherwise.
It's not so much the digging, but watching them yard the orange tubing through said holes... Kind of comical. I watched a team of three tug a bit too hard and nearly fell back into passing traffic (which was ~ 45-50 mph)
The merchant doesn't own the decrypting appliance. The backend merchant sends data to the frontend, who formats and forwards to the backend processor, who then talks to the banks. If the backend has been compromized, your PIN is the least of your worries.
Well the merchant does not have their key - neither does the network. The key is injected into a tamper-sensitive system in the pinpad prior to being shipped. If the battery dies, case is opened, or a strong enough shock (physical) is applied, the pinpad will "dump" it's keys. One of our recent pinpads actually has the pin-containing circuit board encased in a roughly.75"x1"x2" block of solid silicon - try getting through that while not opening the case enough to trigger the keydump...
Slashdot Mirror
/boot, which (usually) contains the grub files (the has is stored in the grub menu config file) is USUALLY readable to all. Ubuntu/debian and friends usually store that as /boot/grub/menu.lst. The password hash is saved in the line "password --md5 HASHVALUEHERE" or, without hash, as "password PASSWORDVALUE" and the boot stanzas are proteced with "lock" if they require the password to be used.
Thanks for the link to the MD5 collision info. Indeed, it still works for passwords.
It's even better because exchange DOES have a retention system. File -> Archive. Hell theres ways for IT to force a retention policy down from group policy!
Blatant lies.
That I understand. But any user who can get into the system enough to read /boot can read that hash, and if they break it they could (probably) set init as anything they want, which could exploit a potential flaw on some kind of security scheme.
If I knew what said flaw in hypothetical scheme was, it wouldn't be so much of an issue. I'm just wondering if the hash itself is safe.
but that brings up another point... what stops someone from booting from something else and just editing the grub config to remove the password? Doesn't seem that there is any real way to secure a system on boot from local access.
Hmm, that is good to know. I assume the MD5 hash you can save the grub password as is safe?
You are assuming Ubuntu. All other distros that I've used (several) need a root password to access level 1.
The summary (did not read the article) states that there was no warning and good indications that accidental death was a possibility. They are after answers, not insights to his mindset.
/etc/shadow (or /etc/passwd if he's a moron, which I doubt) and put your own password hash in.
Just mount the partition with a liveCD, edit
Of course if the drive is encrypted, you are most likely SOL.
Thanks jerks. I had been running hardy off the archive for a week, and was just installing an apache/php/postgres stack when you all decided to crap up the archives.
I don't think you understood what he just said.
He has a little key fob that generates a passphrase based on time and some hidden magic (RSA). The server has one too, with the same hidden magic. Hence, both you and the server will know it, nobody else will until you use it, but once used it's worthless.
It's like a digital OTP.
Example
Get an old-ass laptop with wireless (USB/PCMCIA/MiniPCI doesn't matter) and an ethernet port. Set up ip-forwarding, and stick it between the work laptop and the wireless access point. If your even more paranoid, tunnel the connection to the work laptop to somewhere else (ie, home) so that it is virtually impossible to discern where you actually connected the damn thing (latency being the only real way)
How will they know you didn't just plug it in the wall? The only drawback would be the space for the extra hardware, and looking like a tool while using.
He/She didn't give her/his domain, and presumably if it's never linked to, it will never get indexed. Google doesn't (does it?) randomly try URLs to find sites to index!
I'm not trying to prevent them from seeing sensitive, data, I want to prevent them from seeing any at all! I don't care what they are looking for, I don't want them in any of my business unless they have a warrant! Leaving holes like this are just asking for abuse - witness customs violating and stealing laptops at the border. Yes, I chose those words particularly.
Get your shit together and write your text with the citation at the same time. You don't write a paper for class, then a week after it's graded give the professor your bibliography, do you?
Since my () key broke, I've had to improvise.
about:plugins is what you want. Why this isn't linked or otherwise brought to light, I don't know. I discovered this by trial/error and/or boredom.
On mine, I see this:
Shockwave Flash
File name: NPSWF32.dll
Shockwave Flash 9.0 r47
Explain that to Thomson Course Technology :/
We are using the MS SQL enterprise manager in class (database security) and it bothers me that all this is going on and I really don't have much of a clue what it is doing. I recognize that I'm unusual in that I'd rather spend an assload of time doing it all myself with the documentation and know what is done.
Maybe it's just because I'm not your average bear... but (as a complete DB newbie) I had no trouble discovering and understanding the point of that "su postgres" step. I like the idea that the database is unusable until I say otherwise.
I don't like that either. But what I don't like more is all the hand-holding that gets in my way when I know what I want and how to do it.
Well, unfortunately the internet - and computers in general, are complicated systems. Cry me a river.
</elitist-bastard>
It's not so much the digging, but watching them yard the orange tubing through said holes... Kind of comical. I watched a team of three tug a bit too hard and nearly fell back into passing traffic (which was ~ 45-50 mph)
Well, hopefully the impending PCI DSS will compel merchants and processors to wise up. Hopefully. For now, I think I'll have my nightmares...
To help prevent people from breaking up the posts by putting half of their reply in the subject...
The merchant doesn't own the decrypting appliance. The backend merchant sends data to the frontend, who formats and forwards to the backend processor, who then talks to the banks. If the backend has been compromized, your PIN is the least of your worries.
At least that's how it's done in my world.
I've been playing for two months and I haven't breached level 20 yet. Maybe if you play the game for hours on end...
Well the merchant does not have their key - neither does the network. The key is injected into a tamper-sensitive system in the pinpad prior to being shipped. If the battery dies, case is opened, or a strong enough shock (physical) is applied, the pinpad will "dump" it's keys. One of our recent pinpads actually has the pin-containing circuit board encased in a roughly .75"x1"x2" block of solid silicon - try getting through that while not opening the case enough to trigger the keydump...