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
i got your idea, pooh. but how do you protect bios from being "accessible". i can only see it like on those HSM (hardware security module) where a program is constantly monitoring "physical attacks". if you try to open the "shell", all content will be destroyed. but its not what we want, is it? :lol:
maybe if there is an SECOND processor, that has that logic builtin INSIDE the CPU (like some mainframe, where there is a service processor) that will enable the "comercial cpu" only if you pass thru it --- a hardware firewall?
i cant see how to do that on the SAME cpu.... its like as ATM machime, easy to break :D
See that's what I'm saying.
How would you access the BIOS if the ability to view the configuration is removed? How could you access the BIOS all input except that one scanner is removed from BIOS?
There isn't enough functionality to access the BIOS with, is what I'm saying. Similar to me saying "How are you supposed to access the VCR inside of that house, if I've removed the doors, windows, and the entire house is made out of stone? (top, bottom, and sides).
It isn't about security, it's about functionality. If you don't code something in, there is a loss of functionality. If that BIOS has no possible way to change configuration or for someone to send input to it, then there isn't a way to access it without completely reflashing it. Similar to writing a network protocol that -only- has source code to accept incoming but never send outgoing.
It doesn't matter how much you scream at the network, that source code simply doesn't have the functionality for you to tell it to go out rather than in.
So, it isn't about securing the BIOS. It's about removing what isn't needed, and with that the functionality to change it.
edit: I can only think of one more example to clear up what I'm talking about here. I used to program with some friends of mine a MUD (multi user dungeon, a text based online RPG), and we had a problem with people exploiting the Rent. People, normally, could go to the Inn and 'rent' a room which would save their equipment and gold. However, someone found a way to store unlimited amounts of gold and equipment in there rather than the preset amount we defined.
There were many ways we could solve it, but one of the solutions was to simply remove the ability to store equipment from the Inn. We didn't do that of course, but that's what I'm trying to say here. Sometimes the only way to make people follow rules isn't to write up a set of Laws (or in computer terms, protocols), it's to completely remove instances that would allow it to even occur. We could remove the ability for people to store equipment from the inn, and no one could exploit the storage anymore. We could remove the ability for people to be able to interact with the BIOS (meaning no keyboard input, no mouse input, only that one scanner while BIOS boots), and no one could exploit the BIOS anymore.
This is of course in theory, and I'm glad you are bringing this up :) Good conversation
i liked the idea of cacosapo it is different, and kewl... got most of my attention
i think keeping the functionality is really important
will be thinking a bit, than post my comments
enjoying the conv,really deep, did not expect it will be that deep....
ok, if you talking about "logical security" it will work. but if i lock up the box, why not do that thru O.S.? you cant get access to hard disk anyway... see may point? if you harden enough the box, you dont have concern about o.s. security. but if i can break the hardware (i can hammer your stone walls and enter, and fix the hole before i leave) i can do what i want - including access the bios chip -Quote:
Originally posted here by pooh sun tzu See that's what I'm saying.
Similar to me saying "How are you supposed to access the VCR inside of that house, if I've removed the doors, windows, and the entire house is made out of stone? (top, bottom, and sides).
I don't see what good that does for you. The box is locked up in a room (room security is another matter), but obviously one you can't get to. The BIOS is still out of your reach, and the OS -and- hardware is still secure because of protocol rewriting and limitation coding.Quote:
ok, if you talking about "logical security" it will work. but if i lock up the box, why not do that thru O.S.? you cant get access to hard disk anyway... see may point? if you harden enough the box, you dont have concern about o.s. security. but if i can break the hardware (i can hammer your stone walls and enter, and fix the hole before i leave) i can do what i want - including access the bios chip -
Now you've blown and ruined your own point by pulling the "nothing is secure" argument. Of course you could hammer down the walls, but that just isn't going to happen because of practicality reasons. Are you seriously suggesting that you would just pound through the concret walls into the server? With a harddrive that is still 4000+ encrypted? No security is ever 100% safe, but you can make it hard enough to not be worth the trouble.
So... back at square one. How would you try use the BIOS without the features of inputting to crack a system in another room?
Well apparently all you need is an SUV. :D Thing is what is worth the trouble to you and your company? If it's worth the trouble to encase it in that manner (which removes some availibility issues -- CIA anyone), then it will be worth the trouble for someone to want to break it.Quote:
Are you seriously suggesting that you would just pound through the concret walls into the server? With a harddrive that is still 4000+ encrypted? No security is ever 100% safe, but you can make it hard enough to not be worth the trouble.
So, it is confirmed that we are back at the ever pessemistic "nothing is ever secure" step one. :P
Come on guys. Don't defeat the persuit of an indepth CIA based security model with something as haphazard as "we can just bust the walls down".
But I didn't think we were. It just a matter of thinking outside the box. If we can accept that there is a minute chance of risk (e.g., in reality, how often are ATM taken out via truck? and recognize where that risk is, wouldn't that put us further? I think we do need to be realistic in that creation of this needs to be viable and allow for access to the box for hardware upgrades/repairs.Quote:
Don't defeat the persuit of an indepth CIA based security model with something as haphazard as "we can just bust the walls down".
Also, by simply staying with a single host are we not limiting ourselves? What about a larger system of hosts (given the relatively low cost of machines and other parts) to do this? Perhaps interdependent hosts?
And I don't know if we've identified who the target audience of this concept is. This is an important factor as it determines realistic limits insofar as cost and usability. While the average Joe could use Linux (and some do -- to a degree) many do not and the inertia required to get them to do so is huge (mostly due to the "I have nothing worthwhile to steal" concept).
That's a very different attitude compared to business, who does have something worthwhile to steal and will make attempts to protect it (for the most part). So is this for general use or company use? Are we going strictly theoretical (works great in theory but isn't necessarily viable for mass usage outside of specific environments) and fanciful or are we looking at truly viable?
sorry, my argumentation was not on that direction. I thinking more about if you can get your hardware so secure as you "made", so what is the point to do all the stuff thru the BIOS?Quote:
Now you've blown and ruined your own point by pulling the "nothing is secure" argument.
if i have a security enough hardware, i can do all you have mencioned on a O.S. base. In fact i dont need to do that, since its already present on most O.S. nowadays.
No, that's just it. I acknowledged situations like that and their possibilities. I know people can break down walls and simply steal hardware rather than crack it via software. And?! MsMittens, anyone can say "fsck it, I can break down the wall and get ur server then HARHAR", and the general responce would be "Yeah? And? So what else is new?".Quote:
But I didn't think we were. It just a matter of thinking outside the box. If we can accept that there is a minute chance of risk (e.g., in reality, how often are ATM taken out via truck? and recognize where that risk is, wouldn't that put us further? I think we do need to be realistic in that creation of this needs to be viable and allow for access to the box for hardware upgrades/repairs.
We all already know that such things are possible, and do happen. However, we are -not- talking about room security, guard security, camera protocols, transfer and hardware replacement procedures. Why? Because we are talking about the security of logging into the machine :) That's it. I expanded only briefly upon it (in terms of saying it was in a seperate unreachable room) so that we wouldn't get to where we are now. The "nuh uh!!! We can still BREk into teh R00m!!111five". Because we all know breaking into the room is an option, but hopefully we all remember we are talking about authentation security for the singular computer and not Management Protocol 1010. I tried to avoid that damn "nothing is secure, everything can happen!" because it's so damn obvious. I was hoping people could catch onto why I said the actual compter was in another room.. so we could move foward onto the actual authentiation system in place.
I'm sad that it didn't happen.
I agree on that :) But, as stated in my very first post, I'm not calculating nor planning for additional machines but for a singular 31337 high level security system. This post was never about just one machine. It was about authentation security, and the post I made was merely my thoughts on a much higher level of security than PGP meets firewall.Quote:
Also, by simply staying with a single host are we not limiting ourselves? What about a larger system of hosts (given the relatively low cost of machines and other parts) to do this? Perhaps interdependent hosts?
That's just it though. We don't -need- to determain the target audience, because it won't matter. Security is security, and code has been written for both singular systems and high level systems. As I said above: This post was never about just one machine. It was about authentation security, and the post I made was merely my thoughts on a much higher level of security than PGP meets firewall. Not every post has to be something to teach someone else. And I'm sure most of us saw this post (mind you, he wanted it to be a competition) as a place to discuss ideas on a broad spectrum rather than be limited by the typical conversation we see each and every day on this forum : The singular user on windows/linux that maybe only needs to hide their email every so often.Quote:
And I don't know if we've identified who the target audience of this concept is. This is an important factor as it determines realistic limits insofar as cost and usability. While the average Joe could use Linux (and some do -- to a degree) many do not and the inertia required to get them to do so is huge (mostly due to the "I have nothing worthwhile to steal" concept).
Both. I am going for theoretical on a singluar high level system (example: CIA database or NSA primary SAT coordinator server) and thus it requires a lot of speculation and theory. If other's want to expand more on singular systems for normal home users, then I don't see why they can't do that as well. This thread, at least in my eyes, was meant for the discussion of authentation as a whole rather than trying to single it down to one system and thus everyone reach the exact same conclusion as everyone else has before on this forum. So, welcome both theorietical and viable solutions, but let's not shut down one or the other just yet so we can change the subject to the thread killing "nothing is secure!!11" :)Quote:
Are we going strictly theoretical (works great in theory but isn't necessarily viable for mass usage outside of specific environments) and fanciful or are we looking at truly viable?
Ok. So then sky's the limit to ideas (cost won't be a factor) and it's a singular system. The reason I ask this is because many of the retina/iris scanners out there require a machine to host the database of the biometric info. I went back to re-read your idea again and have some comments/questions:
1. For the biometric scanner: since this is done before the before the bootloader is done but after system check (I'm assuming it does diagnotics to see that everything is there), the database of the biometric is kept in another chip (?) and is unique to the single person using it (or is it a multi-use system). If it's a multiuse system, then there may need to be a seperate CPU/mini-HD to pull this info for each user. (keeping in mind that the biometric used can vary in size from biometric to biometric and that harddrive size is now reaching super miniscule -- about the size of a quarter IIRC Toshiba's claim last year).
2. This login process seems fine and I think it's in use in some places. Rather than fingerprints, perhaps a more "reliable" biometric should be considered or a multiple fingerprint option with live human detection.
3. Again, makes sense. Cost of CPUs, Memory, etc are low so this can be even part of the viable option. What encryption scheme/algorithm to be used between password and OS?
4. Why only terminal access (and by terminal access, do you mean text mode UI or GUI with dumb terminal?) If it's a singluar high level system and you're referring to dumb terminal access then aren't we talking about server/client setup rather than a single user machine? (just for clarification so I know what setup you're thinking of).
I don't really understand the point of securing the boot up of the system if we are going to make an assumption that the physical security of the computer room cannot be broken.
The only reason you would want to secure the bootup of a system is so that the system cannot be booted if it is stolen. You would also not allow for all system users to be able to boot the system. I would imagine that you would instead have a very small group of system administrators that have access to the physical room, and have the ability to start the system through biometric scans. This would get rid of the need to have a huge database of users and biometric data to check against. If the administrators change, the bios chip itself would have to be changed to get rid of the invalid biometric data, and add the new biometric data.. This is really getting outside of the scope of creating a secure login, we are instead talking about total system security(which takes computer theft into consideration), not just login security.
I don't really see that this is part of the login process as a computer system that has to be booted everytime it has to be used would kind of be a pain, and would be extremely limited. For the machine to be useful it has to be connected to other machines, so that the data can be shared in some useful fashion. If you can guarantee the security of the room completely, I could make a DOS machine 100% secure by using a direct crossover cable that runs between the dumb terminal in another room and the DOS machine and a password hashing algorithm such as kerberos combined with a long/complex password requirement. If the only thing you can do at the dumb terminal is enter a login ID and a password there is no possibility of hacking the login other than to bruteforce a password. If you lock out the ID, or lockout(shutdown) the entire system after 3 failed logins why bother with all of the other security as it is not necessary. You can't turn the machine back on after it has been shutdown, so somebody with access to the room has to go boot it back up before you can make more attempts at guessing passwords.
If the physical security of the computer can be guaranteed completely, again, just for the sake of this discussion, there really is no need to secure the bootup. We would just assume that the system is up and running, and as the physical security of the box cannot be violated, there is no possibility of anybody changing the bootup of the system. If you are going to go through the trouble of securing the bootup, you would also probably have to address the issue of how to protect against hardware tampering as protecting the bootup implies that you are trying to protect the machine against theft.
For the reasons above I think assuming that the physical security of the box cannot be compromised is a bad idea, and really limits the spirit of this discussion. Cacosapo's comment about how to secure the bios from tampering is legitimate and you must take it into consideration that the box can be stolen. That doesn't automatically mean that you have to throw your hands up and say that the box cannot be secured just because you can't guarantee that it can't be stolen. As this idea would obviously require that custom hardware be created for this machine it would be a rather trivial task to have the processer run a CRC check against the BIOS code. If the BIOS has been altered in any fashion at all, it would fail the CRC check, and the processor would stop all processing. Since the CPU itself is hardwired, it would require somebody with the technology and know-how to create 65nm chips(the smallest intel makes) to be able to bypass your BIOS bootup routine. Not 100% secure, but pretty damn tough to bypass. And that would just get you past check #1.