Printable View
well here is a topic to disscuss the theory of the ultimate login that can be coded
and maybe at the end we can make a challenge of who codes the best secure application
so what u think? who is in . who is out
well first idea, i think the password should not be stored anywhere, only ur head
encrypting and storing it??? well what u think
So how would the system log you on then or how would an application recognize that you are who you claim you are? If it doesn't have something to compare to (e.g., a hash, biometric, etc.), it won't be able to ensure that the person log on has the authority to do so and will be assigned what resources/permissions they need to be assigned.Quote:
well first idea, i think the password should not be stored anywhere, only ur head
encrypting and storing it???
Perhaps you can clarify or flush out what you meant by "only ur head".
I have enough trouble remembering my house keys never mind an 128-bit encrytion key.
That's one hell of a mnemonics map :D
Actually, the suggestions I've read these days (I think it's somewhere here on AO) is that you use a pass-phrase. That is, rather than a password -- say hgguiteld12 (like I'd remember that -- as they say Memory is the 2nd thing to go) you'd use something like this To be or not to, that's the stupid question! (including spaces and special characters). It makes it easy and allows for a longer than normal password. Plus, users would be less likely to write it down. The trick is to remember exactly how you wrote it (I had one of these once with a PGP exercise for students and forgot how I did it for my private key! D'oh!)
Four level login security (assuming the room itself has no forms of identification security before letting the person in the room, and assuming local login capability):
1. Login code first process would require an retina scan to verify they are someone authorized to use the computer. Without this scan, the computer will not complete the booting process, because the BIOS itself calls upon a security check for the scan. If the retina scan is removed, there is no confirmation and logging process. Consider this a BIOS boot level check with the ability for it to check a network database. There is a 15 second security reset. If the scanner is not used within fifteen seconds then the computer is shutdown again and the event is logged. If a scanner receives incorrect information 3 times in a row, the computer is shutdown again and a "BIOS lock" begins which locks the actual BIOS from booting, and the event is logged.
2. Login code second process, after confirming the retina, would be a biometric confirmation for the operating system to load. Fingerprint authentication would be required during the booting process of the Operating System kernel, meaning only the drivers for the biometric scanner and base OS files (for database checking of the fingerprint) are loaded at this time. The system then halts until a successful match is made and when made the rest of the operating system loads as normal. There is a ten second confirmation match on the fingerprint authentication, and if that time is exceeded the system will shutdown and log the event. There is a three time error policy, in which if the fingerprint authentication is failed three times in a row the system will shutdown and preform a "BIOS lock" (see #1).
3. After those two levels of authentation we have the run of the mill password system. The system itself is encrypted (save /boot) and a passphrase is used to decrypt the system for loading (think pgp for entire partitions). The encryption itself is on 4096 bits and requires an actual passphrase (minumim fifteen words) to decrypt. Once the correct passphrase is inputted through the keyboard the decryption process will begin and the operating system will be loaded. However, there is a 15 second period in which the password must be inputted or face a system shutdown. There is also a three trial attempt on the password, in whichcase if the password fails a third time then an alarm goes off (now that basic OS drivers are loaded we could actually use networking) which results in the system shutting down and preforming a "Bios lock" (see #1) and the event being logged.
4. Have this only be terminal access and have the actual physical server locked up as should be elsewhere. The harddisk is partitioned as needed (usually /home /boot /bin , etc etc etc) and have appropriate read-only permissions set per partitions.
Of course, this could be done both on Windows and Linux, and while it isn't foolproof, there's a base idea we could work with.
I'd use iris scan over retina scan. Iris scans have the lowest FAR/FRR rates of most biometrics I've seen.
Pooh, interesting idea. I wonder how much overhead this would have compared to existing models. And isn't this already in practise somewhere? It strikes me as rather familiar...
Was unaware about the difference of iris to retina :) Good thinking mittens.
I know NSA uses a similar model based on OpenBSD (no longer origonally OBSd, as they've modified the base code enough on their own), but it also includes levels I'm sure they won't publically release. This is only what I know from what they are forced to disclose to the public every few years along with various sources I trust. However, that would mean the information of their security process is most likely also changed and ahead of what they had when they released the information.
CIA uses something similar according to their release documents, but I can't confirm it other than "that's what their documents to the public say"
It's a widely used system, and became effective soon after they learned how easily one could fool a voice identification process. However how "on spot" it is to the real thing of course I would never know. It would be cumbersome in terms of overhead I'm sure. Know of anyway we could streamline that model while keeping the security of it?
So far we are talking about our own low level (possibly assembly) construction of BIOS instructions (for step 1).
My article on Iridian: Iris Scanner <--- has some details that might help.
The only way I could conceive of the overhead being dealt with is a hardware solution but that becomes rather impractical on a large, internet basis (that is, if the intent is to deal with the general populace). This of course begs the question: who is the target audience of this? If it's general population then a software solution would be something to consider or if it's hardware, it has to be cheap as well (cheap, stable and secure -- why should you only have two of three?). If it's business then hardware would be more likely but again, don't want to be too costly. Reality is many companies want security but are finding budgets tighter and tighter. The idea is to get them to use a secure method.
to do that, you will need a large program. So we dont have a "bios" but an entire O/S on ROM.Quote:
So far we are talking about our own low level (possibly assembly) construction of BIOS instructions (for step 1)
although its look more secure, its just a matter to attack the bios, not the o.s. nowadays ppl attacks "software O.S" because its easier. But if you hardlock thru bios, they will instead attack the hardlock - bios program.
my idea :
an external device (USB/card) where you insert your id. when you have inserted your id card (or usb device), system(bios perhaps) will ask the password, that servers to open "the card". if the card "accepts" you, card you send a 4096 key to bios to decript hard disk and start boot (you have encript the HD before with your card).
so, no password stored on disk - you can carry your password with you. Maybe the card can have a fingerprint reader, so it can "see" if you are the owner of the card or not.
ahn, you got me. that device already exists ! (not with bios but as a low level encrypt software)
Not really. BIOS itself runs checks and configuration utilities. The BIOS can sometimes hold up to 16-32k wortk of data and configuration options. If we ripped out all of the "compatability for ALL hardware" and motherboard "features" we don't use, then we have a BIOS customized exactally for the system hardware. And I know writing a simple function to check a database via the BIOS is already possible and implimented in under 4-6k worth of code. We are not talking about ROM :) We are talking about a normal BIOS, but customized for our use.Quote:
to do that, you will need a large program. So we dont have a "bios" but an entire O/S on ROM
Let's think of this, rather than just respond to you. Inside the BIOS code itself is a do/while and a few checks to see if input is being taken from the scanner. Now, since the BIOS is only flashable, and you don't have local access to the harddrive and thus no way to reflash the BIOS, I don't see how they would alter or hack the BIOS? There won't be a "press delete" option because the BIOS won't need it, it's already configured according to the specific needs of the hardware. There won't be a "menu booting and checking RAM" because that feature isn't something that would need to be displayed. There is no configuration menu, because it's already configured and the option to change it is gone from the BIOS chip (reconfiguration is done locally rather than at your 'station').Quote:
although its look more secure, its just a matter to attack the bios, not the o.s.
I don't see how they would attack the BIOS?
That's exactally my point. How? If they can't touch the bios physicaly, and there isn't a menu for keyboard input, and the only recognizable input is from that scanner, then how would they attack the BIOS lock? A lot of systems (server wise) have this feature already built in. It's similar to what happens when your processor overheats, everything locks up. The processor could in fact keep running strong and hot, but instead a safety function is built in for the processor to -simply- stop processing. It's a direct halt. Since they have neither local access to the actual server (remember, locked room, no monitor, no input) nor the BIOs, I don't see how they would bypass something that isn't a program but is instead a low level hardware call.Quote:
But if you hardlock thru bios, they will instead attack the hardlock - bios program.
Hardware calls are much different than "shutdown();", as they directly interact with the hardware. Think: hardware to hardware, rather than hardware to software to hardware. :)
Of course, keep in mind I've somehow moved away from "typical home user" and am now onto "uber l33t mainframe" lol