Security Professionals
- ipfw add deny all from eindgebruikers to any
Login richtlijnen
19-03-2009, 07:54 door Anoniem, 19 reacties
Ik ben bezig met het opstellen van richtlijnen voor het programmeren van een login. Het is wel in het engels. Misschien hebben jullie nog toevoegingen:
-Passwords should never be stored in plain-text ; use md5(“oursalt”.md5($pass)) instead
-Passwords should at least have a length of 9 characters by default ; Customer should be able to adjust this setting according to their companies password policy
-Passwords should be able to be large to allow passfrases (length of at least 256)
-Passwords should be able to hold upper- and lowercase alpanummeric,nummeric and symbols characters
-Users should be able to change their password
-Users should provide their old password when changing their password
-Users should be forced to change their password monthly by default ; Customer should be able to adjust this setting according to their companies password policy
-User should be able to request new (randomly generated) password in case he/she forgot his password
-Login form should block false passwords with a single username after 3+ false retries for at least (false retries/3)*5 minutes
-Login form should block false login attempts from the same IP after 3+ false attempts for at least (false retries/3)*5 minutes
-Login form should not disclose existence of user accounts ; texts like “user does not exist” and “wrong password” should be replaced with “username and/or password incorrect”
-After login , the user should be reported about the last login date/time and failed login attempts
Graag jullie reactie hier op
Greetingz,
Jacco
-Passwords should never be stored in plain-text ; use md5(“oursalt”.md5($pass)) instead
-Passwords should at least have a length of 9 characters by default ; Customer should be able to adjust this setting according to their companies password policy
-Passwords should be able to be large to allow passfrases (length of at least 256)
-Passwords should be able to hold upper- and lowercase alpanummeric,nummeric and symbols characters
-Users should be able to change their password
-Users should provide their old password when changing their password
-Users should be forced to change their password monthly by default ; Customer should be able to adjust this setting according to their companies password policy
-User should be able to request new (randomly generated) password in case he/she forgot his password
-Login form should block false passwords with a single username after 3+ false retries for at least (false retries/3)*5 minutes
-Login form should block false login attempts from the same IP after 3+ false attempts for at least (false retries/3)*5 minutes
-Login form should not disclose existence of user accounts ; texts like “user does not exist” and “wrong password” should be replaced with “username and/or password incorrect”
-After login , the user should be reported about the last login date/time and failed login attempts
Graag jullie reactie hier op
Greetingz,
Jacco
Reacties (19)
19-03-2009, 10:48 door
SirDice
Nooit enige input vertrouwen die een client (browser) naar de server stuurt. Alles, maar dan ook alles, controleren op geldigheid en conformiteit aan de server kant.
Niet filteren op wat je niet wilt hebben maar filter op wat je wel accepteert en verwijder de rest.
Niet filteren op wat je niet wilt hebben maar filter op wat je wel accepteert en verwijder de rest.
19-03-2009, 10:59 door
Napped
Password history
geen dingen zoals bedrijfsnaameigennaam dat je het kan filteren
geen dingen zoals bedrijfsnaameigennaam dat je het kan filteren
In geval van vergeten wachtwoord moet user binnen 10 minuten inloggen en direct het wachtwoord wijzigen, omdat wachtwoorden verzonden via e-mail per definitie niet te vertrouwen zijn
Misschien nog een aardige toevoeging dat het password ook niet in plain-text verstuurd mag worden van de client naar de server. Spreekt misschien op zich, maar je ziet het ook nog vaak gebeuren. Dit zou alle andere moeite zo goed als waardeloos maken naar mijn mening.
Password mag niet her-gebruikt worden.
Nieuw en oud password moeten voldoende afwijkend zijn, dus niet password_1, password_2 etc.
Indien een gebruiker een nieuw password aanvraagt kan dat waarschijnlijk niet per mail omdat deze niet kan inloggen. Er moet dus een systeem bedacht worden om de identiteit van de aanvrager te controleren.
Nieuw en oud password moeten voldoende afwijkend zijn, dus niet password_1, password_2 etc.
Indien een gebruiker een nieuw password aanvraagt kan dat waarschijnlijk niet per mail omdat deze niet kan inloggen. Er moet dus een systeem bedacht worden om de identiteit van de aanvrager te controleren.
19-03-2009, 12:25 door
Zarco.nl
Door SirDiceNooit enige input vertrouwen die een client (browser) naar de server stuurt. Alles, maar dan ook alles, controleren op geldigheid en conformiteit aan de server kant.
Niet filteren op wat je niet wilt hebben maar filter op wat je wel accepteert en verwijder de rest.
Daarbij niet vergeten om ook Cross Site Request Forgery aanvallen te voorkomen die gebruikt kunnen worden om (distributed) brute force aanvallen uit te voeren:Niet filteren op wat je niet wilt hebben maar filter op wat je wel accepteert en verwijder de rest.
- genereer een lange random ID die gecheckt wordt bij het verwerken van de formulier info
- gebruikt POST i.p.v. GET, zodat er geen links van kunnen rondslingeren op het Internet
- controleer de http referer (is niet full proof, maar nietsvermoedende slachtoffers kunnen niet bijdragen aan een brute force aanval)
Geen validatie aan de client kant uitvoeren:
- niet vertrouwen op hidden input velden
- niet vertrouwen op de maximale lengte van input velden
- geen berekeningen door de client laten uitvoeren
Geen zelfgefabriceerde hash / encryptie algoritmen gebruiken.
Indien het een niet-publiekelijk systeem betreft en je hebt genoeg rekenkracht en opslag, zou je misschien woordenboeken kunnen gebruiken om woorden te verbieden. Er zijn genoeg woordenboeken op Internet te vinden.
Zet de webserver in een DMZ en je authenticatie server (bijvoorbeeld RADIUS) in een ander segment.
Test: [url=http://security.zarco.nl]security.zarco.nl[/url]
19-03-2009, 12:26 door
TheFrog
Ik zou een andere retention periode nemen dan een maand, bijv 44 dagen. Mensen zijn dan minder geneigd om de maand in het ww te plaatsen.
Intrusion detection; 5 foute password binnen een kwartier account 30 min. geblocked (bijv)
Password history
Tijd tussen password, dus stel je hebt een password history van 8 password. dat de gebuiker niet binnen het kwartier 8 keer z'n password wijzigd
Wijzig password op eerste login
Suc6
Intrusion detection; 5 foute password binnen een kwartier account 30 min. geblocked (bijv)
Password history
Tijd tussen password, dus stel je hebt een password history van 8 password. dat de gebuiker niet binnen het kwartier 8 keer z'n password wijzigd
Wijzig password op eerste login
Suc6
Ik zie niets omtrent logging, waardoor een audit trail ontbreekt. Indien je advies moet geven, zou je ook nog kunnen aangeven dat multifactor authenticatie evt. een optie is, waardoor kwaadwillenden niets hebben aan enkel een password (i.e. toevoegen van token).
19-03-2009, 13:23 door
meneer
Geen login met behulp van password.
Passwords should never be used. Instead login using OpenID and/or Information Card.
Scheelt een heleboel gehannes met identiteitenbeheer, 'wachtwoord vergeten'. Zullen ook gebruikers gemak van krijgen.
Je moet dan eventueel alleen een mapping maken van de aangeleverde identificatie naar een interne representatie.
Passwords should never be used. Instead login using OpenID and/or Information Card.
Scheelt een heleboel gehannes met identiteitenbeheer, 'wachtwoord vergeten'. Zullen ook gebruikers gemak van krijgen.
Je moet dan eventueel alleen een mapping maken van de aangeleverde identificatie naar een interne representatie.
19-03-2009, 13:40 door
pjhanse
Yubikey zou een oplossing zijn. http://www.yubico.com/
Bestelinfo: http://www.yubico.com/order/index/
Bestelinfo: http://www.yubico.com/order/index/
Door AnoniemMisschien nog een aardige toevoeging dat het password ook niet in plain-text verstuurd mag worden van de client naar de server. Spreekt misschien op zich, maar je ziet het ook nog vaak gebeuren. Dit zou alle andere moeite zo goed als waardeloos maken naar mijn mening.
Ja, dat gebeurt niet alleen vaak, maar dat is zo'n beetje standaard voor web sites zonder https. Als je een wachtwoord verstuurd met IE zal die browser het eerst in plain text proberen. De meeste gebruikers zullen geneigd zijn te denken dat het veilig is.
19-03-2009, 17:08 door
44RT
[rode_Pen_modus]
In het Engels is frase met ph [url=http://en.wikipedia.org/wiki/Passphrase]passphrase[/url]...
[/rode_Pen_modus]
Maar dat even terzijde.
-Login form should lock an account after 3+ false password tries within X minutes for at least (false tries/3)*5 minutes
In het Engels is frase met ph [url=http://en.wikipedia.org/wiki/Passphrase]passphrase[/url]...
[/rode_Pen_modus]
Maar dat even terzijde.
-Login form should block false passwords with a single username after 3+ false retries for at least (false retries/3)*5 minutes
Ik hoop toch maar dat er geen toegang gegeven wordt met een verkeerd wachtwoord!!! Ik snap wel wat je hier bedoelt (je bedoelt hier toch dat de gebruikers account geblokkeerd wordt na drie keer het verkeerde wachtwoord te hebben ingevoerd voor één account?) maar ik zou dat wat beter omschrijven. Misschien kun je hier ook nog een tijdsdimensie aan toevoegen (3 verkeerde wachtwoorden binnen een X aantal minuten). Dus:-Login form should lock an account after 3+ false password tries within X minutes for at least (false tries/3)*5 minutes
Het is wel veilig maar totaal onpraktisch.
Voor een bank is veiligheid belangrijk, maar voor een simpel iets zoals een forum is het overbodig en irritant.
Voor een bank is veiligheid belangrijk, maar voor een simpel iets zoals een forum is het overbodig en irritant.
19-03-2009, 20:46 door
[Account Verwijderd]
[Verwijderd]
Even vanuit een hoger niveau bekijken:
Wat ik hier zie en ook de reacties is allemaal erg specifiek over *hoe* je dit goed en steeds beter kan doen. Prima tips maar het is m.i. een beetje te geisoleerd.
Maar ga eerst even een stapje terug en stel vast waar je het voor doet. Is het een bedrijfje om toegang te verlenen voor medewerkers? Een website met gebruikers? Wat voor gegevens bescherm je? Hoe belangrijk zijn die etc. Probeer eisen op te stellen vanuit je bedrijfs- of organisatiedoel. Bepaal hoeveel geld/inspanning je er voor over hebt. Wat is het beleid van je bedrijf/organisatie. Het is namelijk onzin om relatief onbelangrijke info te beschermen met zware beveiligingsmethoden. Bedenk ook welke aspecten belangrijk zijn: vertrouwelijkheid, beschikbaarheid, integriteit, ...
Het kan ook zo zijn dat de informatie zo belangrijk is waar je bij kan als je aanlogt, dat uid/pw helemaal niet goed genoeg is. Dan moet je bv naar 2 factor authenticatie (of beter). Denk ook aan gelaagde beveiliging. Logging, audit trails, IDS, IPS, etc Wat wil je met de logon ontsluiten? Heb je single signon nodig om nog meer apps te ontsluiten. Denk ook aan achterdeuren, je kunt de voorkant dichtzetten met 3 factor authenticatie, maar je serverruimte is niet op slot.
Je kunt altijd een stapje beter met je logon procedures, de vraag is waar je ophoud want hoe beter hoe duurder (iha).
Wat ik hier zie en ook de reacties is allemaal erg specifiek over *hoe* je dit goed en steeds beter kan doen. Prima tips maar het is m.i. een beetje te geisoleerd.
Maar ga eerst even een stapje terug en stel vast waar je het voor doet. Is het een bedrijfje om toegang te verlenen voor medewerkers? Een website met gebruikers? Wat voor gegevens bescherm je? Hoe belangrijk zijn die etc. Probeer eisen op te stellen vanuit je bedrijfs- of organisatiedoel. Bepaal hoeveel geld/inspanning je er voor over hebt. Wat is het beleid van je bedrijf/organisatie. Het is namelijk onzin om relatief onbelangrijke info te beschermen met zware beveiligingsmethoden. Bedenk ook welke aspecten belangrijk zijn: vertrouwelijkheid, beschikbaarheid, integriteit, ...
Het kan ook zo zijn dat de informatie zo belangrijk is waar je bij kan als je aanlogt, dat uid/pw helemaal niet goed genoeg is. Dan moet je bv naar 2 factor authenticatie (of beter). Denk ook aan gelaagde beveiliging. Logging, audit trails, IDS, IPS, etc Wat wil je met de logon ontsluiten? Heb je single signon nodig om nog meer apps te ontsluiten. Denk ook aan achterdeuren, je kunt de voorkant dichtzetten met 3 factor authenticatie, maar je serverruimte is niet op slot.
Je kunt altijd een stapje beter met je logon procedures, de vraag is waar je ophoud want hoe beter hoe duurder (iha).
20-03-2009, 09:11 door
Mike1974
Wellicht is het de moeite waard om je niet enkel en alleen op username/password als login methode te richten.
Je zou ook tokens, SMS-based OTP, en client certificate/smart-card mee kunnen nemen in deze handleiding.
Je zou ook tokens, SMS-based OTP, en client certificate/smart-card mee kunnen nemen in deze handleiding.
20-03-2009, 12:11 door
wimbo
Door Anoniem
Password mag niet her-gebruikt worden.
Nieuw en oud password moeten voldoende afwijkend zijn, dus niet password_1, password_2 etc.
[...]
Dat gaat lastig worden als je de wachtwoorden op je back-end gehasht opslaat. 1 karakter verschil en je hash is anders.Password mag niet her-gebruikt worden.
Nieuw en oud password moeten voldoende afwijkend zijn, dus niet password_1, password_2 etc.
[...]
Je zou op voorhand een controle kunnen doen op een dictionary + volgnummer ofzo, maar dan loop je weer de kans dat je applicatie erg traag wordt. En waar ga je de grens leggen?
Hashes van oude wachtwoorden kan je vergelijken, maar variaties op het thema wordt lastig, omdat je niets voor de vergelijking hebt.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
