Be un discorso sulla sicurezza sarebbe davvero lungo.

Sicuramente sono d'accordo in generale sull'uso di https in modo che le pass non girino mai per la rete in chiaro, altrimenti il resto è inutile.

Poi suggerisco posso suggerire qualche tematica da approfondire navigando su BigG.

Per esempio, quando un utente si registra, salvare la password con un algoritmo di criptazione non reversibile e ricorsivo. Per esempio bcrypt o il più recente "scrypt". Non potrei inserire link, ma qui se ne parla un pò:
stackoverflow.com/questions/4433216/password-encryption-pbkdf2-using-sha512-x-1000-vs-bcrypt?rq=1

Poi sarebbe un'ottima idea obbligare l'utente ad inserire una password da almeno 8 caratteri con:

• almeno un simbolo
• almeno una lettera maiuscola
• almeno una lettera minuscola
• almeno una cifra numerica

Poi per ulteriore sicurezza potresti aggiungere alla password una SALT, cioè una stringa random (e quando parlo di random intendo estratta con la funzione openssl_random_pseudo_bytes su php) e avviare l'algoritmo di criptazione con dentro la salt. Ne devi generare uno per ogni utente, salvarti la salt nel database insieme al nome utente ed alla pass. In questo modo se ti rubano il db degli utenti ci metteranno una vita a fare un brute force sui dati.

Si potrebbe aggiungere anche un authtoken al form per verificare che i dati in arrivo siano stati inseriti nello stesso form generato inizialmente dal server. Salvi l'authtoken in sessione mandi il form al client con l'authtoken in un text hidden e lo ricontrolli se corrisponde quando il client reinvia i dati al server. Se sei in una connessione HTTPs serve meno.

In alternativa all'HTTPs, non è molto elegante, ma puoi avviare una negoziazione RSA tra client e server con javascript lato client e php lato server. La negoziazione porta client e server a scegliere una chiave comune per una normale criptazione simmetrica che è più veloce. A quel punto per ogni comunicazione riservata client-server cripti e decripti con la chiave negoziata.

Infine, ma non ultimo, direi di mettere tutti i file con le class di gestione del login e database in una cartella sul server all'esterno dell'area raggiungibile dal web.

Spero di "essere stato spiegato"

beh...per non fasciarmi troppo la testa con algoritmi di criptazione aggiornati uso il solito sha, però oltre a identificare ogni sessione con un capo del database che seguo aggiornando la "last action", non permetto il doppio login stroncando la sessione di chi è già loggato e setto per ogni utente un failed_login per evitare i brutal force. In questo modo dopo n tentativi l'account viene bloccato. Almeno t'accorgi se ti prendono di mira e casomai filtri l'ip.

Però il discorso dell'authtoken mi fa riflettere: data una sessione di un'utente in un server lamp, è possibile intercettare la sessione e mettersi al suo posto?

intanti se usi https in pratica è difficilissimo essendo la comunicazione criptata.

La risposta alla tua domanda dipende da molti fattori. Per prima cosa per meglio tutelarsi devi impostare il server in modo da non aggiungere mai l'id di sessione all'url delle pagine.
Poi spesso nella sessione si salva in sha una stringa che può contenere user agent ip e salt dell'applicazione. In questo modo la stringa dipende dal pc dal quale l'utente si è loggato e dalla connessione che usa e chi anche avesse intercettato l'id di sessione avrà la difficoltà di sapere quale user agent stava usando l'utente, di camuffarne l'ip e di non saperne la salt.

In poche parole, non credo sia così semplice bucare un sistema con certe accortezze, almeno non dal modulo di login. Poi uno magari dimentica di filtrare l'input e gli fan saltare tutto da lì

mmm quanta roba!
Non so da dove partire. Troppe accortezze!
Pensavo di avere una buona dose di sicurezza avendo usato le accortezze per evitare l'sql injection, avendo spostato la directory in cuui vengon salvate le sessioni e avendo criptato le password nel DB con algoritmi di cifratura già consolidati.
Però non avevo minimamente considerato, per esempio, il fattoo di generare un authtoken nel form e compararlo, oppure aggiungere un salt nelle password e via dicendo.
A sto punto considererei l'idea di usare un framework per il login come oAuth. Altrimenti, vi andrebbe di postare un elenco di misure da adottare? Magari potrà essere utile anche ad alltri utenti.

EDIT: stavo guardando qualche venditore di certificati SSLe ne ho trovato uno base da circa 8€/anno e nelle specifiche mi da 10.000€ di garanzia (che non so che significa) e mi chiede di avere IP dedicato e CSR.
Potete darmi anche qualche dritta su cosa mi serve per avere un hosting SSL e se ce ne stanno anche di lowcost per iniziare?
Grazie.

Per usare quel certificato devi avere una tua macchina già configurata con ssl e avere un ip dedicato (1ip => 1 certificato) almeno è come l'ho capita io, qualcuno piu esperto di me confermerà

Se vuoi un certificato ssl (quello che trasforma la tua pagina in potenziale https per intenderci) sei obbligato ad avere ip dedicato. Cmq, tra i vari sistemi di sicurezza hai pensato di controllare TUTTE le variabili che l'utente può passare? siano esse get e post? anche quelle di sistema... devi filtrarle e controllarle tutte.

si ovviamente quello di controllare le variabili l'ho fatto.
A sto punto penso di usare oAuth, ma vorrei sapere se questo mi garantisce piu sicurezza vito che è usato da colossi come facebook, twitter e google.

Attento oAuth è un sistema approvato dai "colossi", la criptazione SSL è quella che entro certi limiti ti garantisce la sicurezza.

ma riguardo ad avere un https qualcuno saprebbe dirmi cosa serve oltre ad un ip statico ed un certificato SSL?
Se non fosse possibile in pubblico potreste linkarmi in privato qualche link di qualche hosting, magari low cost (ammesso che ne esistano) ?

@Tarab, mettiamo in chiaro qualche concetto:

• per utilizzare HTTPS non "serve" un certificato SSL rilasciato da un authority. HTTPS è solo un protocollo di comunicazione, un certificato SSL è tranquillamente creabile con openssl, un software che gira sotto linux e che è presente di default nelle distribuzioni server. Tutto ciò che serve è poter disporre via Apache della porta 81 o 443, le porte di solito utilizzate per l'HTTPS;
• per essere credibile ed affidabile agli occhi dei clienti, bisogna avere invece un certificato SSL rilasciato da un authority. Un certificato "creato in casa" dal tuo openssl, varrebbe a livello di sicurezza perché è pur sempre una chiave criptata, ma non varrebbe a livello di immagine;
• quello che tu chiami low cost, si chiama SSL Shared Hosting, fai il copia incolla di queste parole su Google e troverai tante aziende che lo offrono.