When you meet him why don't you give him a TSL private key+signed cert on a USB key? Then you will allow access only if cert is properly signed. the private key can be protected by a secret. It is easier to do than it seems at first :-)
mic 2010/10/10 mdipierro <[email protected]>: > adding the three attempt limit is a good idea. > > On Oct 9, 10:56 pm, Magnitus <[email protected]> wrote: >> Well, technically, you can't access the admin unless: >> >> 1) You have local access >> >> and/or >> >> 2) You are using TLS >> >> So if you site isn't using TLS, the admin is disabled and you are safe >> (even if your generic users aren't). >> >> However, I dislike the amount of power you have in one place with the >> admin app. >> >> I'd prefer to break it down into several sections that I need and make >> various sections available to different roles with user accounts. >> >> In particular, I find the ability to edit the controllers/models >> remotely seldom useful in a deployment server (what I'd want to do if >> I need to modify code after deployment is to modify a secondary test >> server, test the mods and then propagate the modified files to the >> production server) and extremely compromising if someone breaks in >> (yes, in a perfect world, nobody should be able to login as the admin >> except the admin and so it doesn't matter if all hell breaks lose if >> someone manages to do so right?). >> >> For that reason, I don't include the admin in the list of accessible >> urls in the routing file. >> >> I think disabling the admin after 3 consecutive unsuccessful login >> attempts wouldn't be that hard to implement, but as I don't use the >> admin for reasons mentioned above, I think it would be more >> interesting to disable user accounts after 3 unsuccessful login >> attempts (assuming that administration is based on role-based access >> with user accounts). >> >> Then, whether its good to implement the 'disable after 3 login >> attempts' measure depends on the situation. >> >> If secret usernames are used to login, its a decent security measure. >> >> If emails or public usernames are used to login, it would be easy for >> someone to do a DoS attack on a particular user they don't like by >> repeatedly try to login as the user using a wrong password to lockdown >> his account (lets face it, some people are just mean). For this >> reason, I also think it might be bad to implement it on the admin app >> if you are using it (once someone has found the app, they could >> perform DoS attacks on the admin with impunity). >> >> So assuming that the admin section uses role-based access with an >> account that doesn't have a public username and that the username is >> something a little more subtle than 'admin', then it wouldn't be a bad >> thing to implement the 'disable after 3 login attempts' measure. >> >> Another interesting alternative to prevent brute force attacks, at >> least for the admin (might annoy regular users), would be the use of >> captchas. >> >> On Oct 9, 10:39 pm, Richard <[email protected]> wrote: >> >> > > 3) I'd also limit the IP access to the artist's home IP, but his IP >> >> > will probably be dynamic. Maybe limit the area, I'll see. >> >> > I've got some apps around the web with the admin exposed and haven't >> > had any problems. Though it probably helps that nothing links to them. >> >> > Could you modify admin so that it locks the account after a number of >> > successive password failures? >> >> > On Oct 7, 6:44 pm, Magnitus <[email protected]> wrote: >> >> > > I am in the process of securing the help of an artist for my project, >> > > but he's a casual computer user (doesn't know ssh/scp) and I'm trying >> > > very hard to make everything as painless and pleasant as possible for >> > > him to secure his help. >> >> > > In order to do that, I decided to create a view that will allow the >> > > artist to download and upload pictures in the "static" folder of my >> > > app (similar in concept to the facility provided to translators for >> > > the languages, except with more fine-grained access control). >> >> > > Question 1: >> >> > > My current strategy (security-wise) is: >> >> > > 1) Limit the associated controller to the artist's role >> >> > > 1 a) A strong and unchangeable password will be provided to the artist >> > > (in a face-to-face meeting). >> >> > > 1 b) Everything will go through TLS. >> >> > > 2) Limit downloads/uploads to .png/.gif/.jpg files (main pitfall if >> > > part (1) fails: not sure what would happen if a malicious user >> > > uploaded a malicious script/binary as an image... my guess is not much >> > > except for a very weird-looking picture for the users... possible >> > > webside defiguration there as well). >> >> > > 3) I'd also limit the IP access to the artist's home IP, but his IP >> > > will probably be dynamic. Maybe limit the area, I'll see. >> >> > > 4) The artistis account will be deleted once the work is done. >> >> > > Any blatant oversight or possible improvement to this model? >> >> > > Question 2: >> >> > > The pictures in the static folder are constantly being read-accessed >> > > during web-page requests. >> >> > > My guessing is that not much will happen if the artist downloads an >> > > image. >> >> > > However, any possible complications if the artist uploads (and thus >> > > overwrites) one of the pictures while a page needing it is requested? >> >> > > Thanks in advance for the feedback. >> >>
