Jump to content
edumad

Pontos fracos em termos de segurança

Recommended Posts

edumad

Boas.

Vou implementar autenticação no meu projecto.

Vou guardar a password do admin num ficheiro txt usando md5 ou sha1 (qual é melhor?).

Quando o admin acede ao site, entra a password uma vez, e é criada uma session.

A session terá em principio uma só variável, que verifica se isset para ver se o admin fez login.

Não quero usar cookies, para isso tenho de por session.use_cookies = 0 certo?

Quero que a sessão seja limitada a 10 minutos (session.cache_expire=10, certo?)

Com estas medidas as unicas falhas de segurança que eu posso encontrar são.

O admin faz login a sai do pc, deixando-o disponivel durante 10 min...

Alguém apanha os packets na rede (?), apanhando a password. Como é que eu posso esconder o txt da password para que passe pela net mais "escondido": ssl? como funca?

O sistema é suposto resistir apenas a uns wize guys em informática e não a crackers. A segurança a sério do servidor vai ser feita por outro ppl, quero é que a forma como a site faz a autenticação não seja uma das fraquezas do sistema.

Share this post


Link to post
Share on other sites
Ped@ntilva

Eu não te sei responder às perguntas mas acho que guardar em .txt não é boa ideia.

É melhor usar uma BD.

Cumps

Share this post


Link to post
Share on other sites
Warrior

É para saber se o user fez o login correctamente ou não..

Para evitar que seja apanhada na rede julgo que não há solução possível.. alguem que esteja a verificar a comunicação entre os dois lados sabe sempre que resposta dar no futuro quando o servidor fizer as perguntas..

Para evitar trojans podes fazer uma mistura de password e clicks, como se vê em muitos bancos que se tem que marcar o codigo num teclado digital..

Share this post


Link to post
Share on other sites
satanuke

Basicamente é assim, apartir do momento do login do utilizador, todas as páginas protegidas vão fazer validações para saber se o user está "loggado" ou não e se tem permissões para as ver.

Para isso tens possibilidade de usar Cookies ou Sessions ou ambos, se usares cookies das-lhe um tempo de vida para que sempre que o browser abra a página ele faça logo login, se usares só sessions, a sessão é terminada quando fechares o browser e terás que fazer login da proxima vez.

Por opinião pessoal, não gosto muito de guardar passwords em cookies, sinto-me inseguro mesmo que ela esteja codificada em md5, para mim tudo o que seja importante nunca deve ficar do lado do cliente e ficar o mais seguro possivel no servidor mas por exemplo para a funcionalidade do "remember me", guardar username e password em cookies é imprescindivel...

Share this post


Link to post
Share on other sites
edumad

Eu cookies, também não penso usar, e penso que só se justifica para comodidades (login automatico - pode ser perigoso) e quando o teu site tem um alto nivel de personalização (foruns por exemplo).

O que eu estou a fazer é criar uma sessão e definir uma var: $_SESSION['logged']='yes';

depois as páginas vão checar se a var está deifinida.

Já agora, não há forma de criar a sessão artificialmente pois não? Criar a sessão sem fazer login. Não percebo muito bem como funcam as sessões... como eu faço session_start(), mas como é que o server sabe que sessão ir buscar?

Também estou com um problema, a sessão acaba automaticamente quando fecho o browser, mas para ficar ainda mais seguro do lado do utilizador (admin) quero que a sessão dure apenas 20 minutos (ao contrário dos 180 min defult), não estou a conseguir fazer isso com: session_cache_expire(20); (repito o comando a cada session_start()).

Share this post


Link to post
Share on other sites
Warrior

para isso basta na base de dados que possui os usernames e as passwords, adicionar um campo extra como "time"

Quando o user fizer login, guardas aí o timestamp da hora actual (número de segundos desde 1 janeiro de 1970). A cada novo request, fazes a comparação do timestamp actual com o gravado.

Quem diz campo na base de dados diz num ficheiro ou qualquer coisa permanente. No teu caso, usaria sessions mesmo.

Share this post


Link to post
Share on other sites
alfatek

Ou eu dormi mesmo mt pouco, ou parece-me que há aqui algumas confusões.

Sessions e cookies não são "tecnologias" alternativas. As Sessions são um conceito de alto nivel mas que usam cookies para manter o estado. As sessions podem funcionar com base noutra coisa que é passar o sessionid no endereço.

Em termos de segurança é irrelevante se usas cookies ou metes o sid no endereço. Qualquer pessoa que escutar a rede vai apanhar o pedido http. Nesse pedido http ele ou lê o conteudo da cookie ou vê o endereço da página com o SID no fim. (é um bocado mais fácil pelo endereço, porque nem é necessário criar uma cookie falsa, é só mesmo copy paste do endereço)

Nenhuma das opções é minimamente segura e tens de confiar que a rede é segura até ao website, caso contrário é impossivel garantir a segurança porque todo o trafego HTTP não é encriptado.

Se pretendes segurança a única solução é que o servidor seja HTTPS (SSL) e nesse caso a comunicação é encriptada e já é minimamente segura. Se usas cookies ou não, é irrelevante. Isso é implementado a nível do servidor (apache, etc).

Quanto ao ficheiro, ele deve estar obviamente, fora da public_html/. Dependendo de como são feitas as coisas usares o ficheiro pode ser mais ou menos seguro que a BD. Mas normalmente é mais seguro meter na BD porque ela já vem "de raiz" com alguma segurança, enquanto que em ficheiro é preciso que o sistema operativo garanta que mais ng pode aceder ao ficheiro, etc.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.