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. > >
