EdorFaus <[email protected]> wrote:
>On 10/11/2012 03:26 AM, Alexander Stephen Thomas Ross wrote: >> On 11/10/12 01:40, Freemor wrote: >>> Next version is planned to: >>> hashed password > >> For hashing md5,sh1 are cracked. So SHA224 or 256? Is SHA*** over >kill? > >I would think that the proper thing to do would be to use the system >password for the user that is logging in (which is probably root here), > >and to use the existing libraries etc. for that part of it instead of >reimplementing it yourself. > I agree but was unable to find the normal login command in the default BNN packages. >That would let you ignore how exactly the password is hashed and >stored, >since that's taken care of for you by the system (and probably at least > >as securely as you'd manage yourself), and also means the user can use >the standard tools for setting the password (such as the "passwd" >command), and gets to use the same password for ssh logins. > >That would make it basically equivalent to an X display manager (such >as >gdm), or maybe an X screen locker, just specialized for our purposes >instead of managing X displays. > >I'll admit that I've never done this myself, so I don't know how hard >it >would be to implement the login bits properly, but it *has* been done >before, so it must be possible... > >You may want to take a look at libpam, if PAM is used on the NN, or >maybe the "login" program (from the (installed by default) package with > >the same name in Debian). (I don't have my NN right now to check if it >has those things myself.) I'll check to see if the stock install of python includes a libpam module. > >As for making it only show up at boot, that could probably be done by >putting it in the boot process before gmenu2x, and having the boot >process wait for it before continuing. I insert it directly into inittab (where the normal login process would go). This also covers your later concern re VTs as I insert it before all of them. > >Possibly better/easier would be to keep it where you have it, so that >it >runs before gmenu2x always, but keep a marker file on a tmpfs somewhere > Definitely mulling this, seems the way to go. >that is created after a successful login and makes it "autologin" when >present. That would also allow you to make a "lock screen" app that >simply deletes that file... > >Another thing to consider is that it is usually possible to switch to a > >different VT, so you'll probably want to either block that, or (better) > >ensure that those other VTs require login as well (which should be >fairly easy to do by configuring init, I think). My primary goal was to protect mislaied BNN's and provide a means for the person who finds it to know whom to contact (Thought I had lost mine at one point). I also wanted to do this on as close to a "stock" BNN as I could. with the BNN's limited resources pulling in a bunch of extra stuff seemed a bad idea. _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
