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 <richar...@gmail.com> 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 <eric_vallee2...@yahoo.ca> 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. > >
