[htaccess] Maximale security

Pagina: 1
Acties:

  • Baxlash
  • Registratie: Juni 2000
  • Niet online

Baxlash

Its a boy Genius!

Topicstarter
Mensen,

Ik zit momenteel in een denk-probleem ;)

Het volgende:
Ik ben bezig met een compleet systeem voor een bedrijf, met klantgegevens, en andere prive informatie erin. Alles draait al, met een firewall eraan die alles blokkeerd. Niemand vanaf internet zou 'theoretisch' gezien niet bij de database kunnen komen.

Nu is de vraag van het bedrijf gekomen dat ze vanaf thuis ook de database in kunnen. Dit wilde ik zowiezo met een .htacces gaan doen via https.

Nu is er natuurlijk altijd een optie om binnen te komen, zoals brute force. Ik wil de passwords random laten genereren zodat dat ook vrijwel uitgesloten is.

Het probleem nu is, is dat het 'vrijwel' uitsluiten niet voldoende is. Wat ik heb bedacht is om de toegang te blokkeren in de firewall zodra er 3x het wachtwoord verkeerd is ingevoerd.

Zijn er mischien nog betere oplossingen? VPN en dergenlijke is geen optie doordat veel een eigen thuisnetwerk hebben waar het niet door hun eigen 'zelfbouw' servertje heen komt.

  • MisterData
  • Registratie: September 2001
  • Laatst online: 22-08 19:41
Tsja.... misschien beter om de toegang voor dat IP adres voor 1 minuut (en bij meer verkeerde 'gokjes' langer) te ontzeggen. Zo maken brute-force systemen geen kans omdat ze veel te lang moeten wachten. Verder moet je zorgen voor voldoende moeilijke wachtwoorden natuurljik :)

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Zodra jij de wachtwoorden random gaat laten genereren (hoe komen ze er dan in) dan heb je het volgens mij al beter beveiligd dan de gemiddelde site. Er zit bij zo'n tight security eerder een risico bij de gebruikers die wachtwoorden gaan opschrijven enz.

en als die mensen statische IP's hebben is een iprange inc/exclude natuurlijk ook wel een sjieke (nog moeilijker te omzeilen) oplossing. Let wel op; je moet kiezen tussen functioneel of gebruiksvriendelijk...

[ Voor 0% gewijzigd door Spider.007 op 14-10-2002 16:33 . Reden: addenum ]

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate


  • Baxlash
  • Registratie: Juni 2000
  • Niet online

Baxlash

Its a boy Genius!

Topicstarter
MisterData schreef op 14 oktober 2002 @ 16:30:
Tsja.... misschien beter om de toegang voor dat IP adres voor 1 minuut (en bij meer verkeerde 'gokjes' langer) te ontzeggen. Zo maken brute-force systemen geen kans omdat ze veel te lang moeten wachten. Verder moet je zorgen voor voldoende moeilijke wachtwoorden natuurljik :)
Hmm dat is idd ook een goed idee... Maar is het niet zo dat de kans groot dat er gebruik gemaakt wordt van een anonieme proxy, of iedergeval een andere manier waarop ze toch in veelvoud in kunnen proberen te loggen?

Natuurlijk is het haast niet haalbaar, maar hoe moeilijker het gemaakt wordt des te beter het is...

  • Baxlash
  • Registratie: Juni 2000
  • Niet online

Baxlash

Its a boy Genius!

Topicstarter
Spider.007 schreef op 14 oktober 2002 @ 16:31:
Zodra jij de wachtwoorden random gaat laten genereren (hoe komen ze er dan in) dan heb je het volgens mij al beter beveiligd dan de gemiddelde site. Er zit bij zo'n tight security eerder een risico bij de gebruikers die wachtwoorden gaan opschrijven enz.

en als die mensen statische IP's hebben is een iprange inc/exclude natuurlijk ook wel een sjieke (nog moeilijker te omzeilen) oplossing. Let wel op; je moet kiezen tussen functioneel of gebruiksvriendelijk...
Gebruiksvriendelijk hoeft het niet perse te zijn, dat is alleen mooi meegenomen... Statische ip's hebben de gebruikers helaas niet doordat ze vrijwel allemaal bij kabelfoon of wanadoo zitten :(

Verwijderd

Mischien overbodig om te noemen hoor, maar of je je password nu om de seconde veranderd of niet, via bruteforce zullen ze op beide manieren er (theoretisch) even snel achter komen...

Mischien kan je een soort van login systeem maken, wat bruteforces detecteerd, en bij een detectie dus gewoon heel het ip blockt.
Ik zou alleen niet weten hoe je dat in een htaccess file kan proppen...

  • Baxlash
  • Registratie: Juni 2000
  • Niet online

Baxlash

Its a boy Genius!

Topicstarter
Verwijderd schreef op 14 oktober 2002 @ 19:54:
Mischien overbodig om te noemen hoor, maar of je je password nu om de seconde veranderd of niet, via bruteforce zullen ze op beide manieren er (theoretisch) even snel achter komen...

Mischien kan je een soort van login systeem maken, wat bruteforces detecteerd, en bij een detectie dus gewoon heel het ip blockt.
Ik zou alleen niet weten hoe je dat in een htaccess file kan proppen...
passwords regelmatig veranderen is natuurlijk zowiezo wel een goed idee leek mij. Zoals bovenstaand is het mischien een goed idee na 3 keer proberen te blokkeren, of dat je over 10 min weer mag inloggen. Zo duurt het veel ste lang voor een brute force om er achter te komen. Eerder dat een brute force zo ver is, is het wachtwoord al weer veranderd. Of bekijk ik dit verkeerd?

Verwijderd

passwords regelmatig veranderen is natuurlijk zowiezo wel een goed idee leek mij. Zoals bovenstaand is het mischien een goed idee na 3 keer proberen te blokkeren, of dat je over 10 min weer mag inloggen. Zo duurt het veel ste lang voor een brute force om er achter te komen. Eerder dat een brute force zo ver is, is het wachtwoord al weer veranderd. Of bekijk ik dit verkeerd?
Bedenk wel dat als je passwords 'regelmatig' verandert, toegang wel erg lastig wordt voor de gebruiker. Maar vooruit, dat maakt niet uit, zeg je zelf al

Het gaat er denk ik niet om dat pw's snel dmv brute forse gekraakt zouden kunnen worden. Als je een pw-hash opslaat in je database wordt, hoef je er echt niet bang voor te zijn dat die binnen ... tien minuten, een uur ofzo gekraakt wordt (als je maar een 'sterk' pw hebt). Probleem is vaak eerder dat niet het pw gekraakt wordt, maar dat de implementatie van je app niet goed is. Dit kan er soms toe leiden dat iemand toegang krijgt ZONDER dat er uberhaupt gekraakt hoeft te worden (bv dmv sql injection kun je toegang krijgen als je alleen een username hebt, zonder pw. Let hier ook zeker op!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Baxlash schreef op 14 oktober 2002 @ 16:23:
Mensen,

Ik zit momenteel in een denk-probleem ;)

Het volgende:
Ik ben bezig met een compleet systeem voor een bedrijf, met klantgegevens, en andere prive informatie erin. Alles draait al, met een firewall eraan die alles blokkeerd. Niemand vanaf internet zou 'theoretisch' gezien niet bij de database kunnen komen.
Niemand kan er niet bij? Iedereen kan er dus wel bij?
Nu is de vraag van het bedrijf gekomen dat ze vanaf thuis ook de database in kunnen. Dit wilde ik zowiezo met een .htacces gaan doen via https.
Zijn er mischien nog betere oplossingen? VPN en dergenlijke is geen optie doordat veel een eigen thuisnetwerk hebben waar het niet door hun eigen 'zelfbouw' servertje heen komt.
SSH met port-forwarding?

  • DiNo!
  • Registratie: Juni 2000
  • Laatst online: 21-08 12:20
Baxlash schreef op 14 oktober 2002 @ 16:23:

Zijn er mischien nog betere oplossingen? VPN en dergenlijke is geen optie doordat veel een eigen thuisnetwerk hebben waar het niet door hun eigen 'zelfbouw' servertje heen komt.
Je kan natuurlijk stellen als eis dat de klant een bepaalde router (draytek 2200e ofzo) moet hebben om dan een permanente VPN op te stellen. Dan heb je natuurlijk ook geen last meer dat de 'zelfbouw' servers misschien niet alles doorlaten of dat als deze het niet meer doet dan de klanten gaan bellen dat er iets niet werkt aan jouw server terwijl het die van hun zelf is. :*)

https://github.com/atoomnetmarc/


  • frickY
  • Registratie: Juli 2001
  • Laatst online: 21-08 23:34
Client SSL verification

Geef alle gebruikers een 'home-brew' (met OpenSSL) client certificaat welke je op je server checked.

Zo kunnen in ieder geval alleen de mensen met dee certificaat in je systeem komen.

Dat is tenminste wat ik van client-verification via SSL weet...
Pagina: 1