Ja, browsers kunnen doen wat ze willen en er is via HTTP(S) geen manier om bepaald gedrag af te dwingen. Je kunt hoogstens hints geven (vriendelijk vragen) om van bepaald gedrag af te zien.

P.S. Welke authenticatie gebruik je? HTTP-basic is wel heel basic.

De browser bewaart geen wachtwoord als je inlogt.
Er wordt een cookie geplaatst waarin staat dat de gebruiker is ingelogd.
Verander de inlogduur in de cookie.
Als die is verlopen moet opnieuw worden ingelogd.
Het verwijderen van een cookie doet hetzelfde.
Met een session kan je de inlog verversen zodat de gebruiker niet halverwege wordt uitgelogd.
Vaak kan je bij de browserinstellingen opgeven dat cookies worden gewist bij het sluiten van de browser.

https://stackoverflow.com/questions/32881993/session-timeout-for-login-page

Tja, zoals zovaak het geval is hebben de browsers hier oorspronkelijk wel support voor gehad, maar hebben de ontwikkelaars in hun oneindige wijsheid later weer besloten dat dit geen goed idee was en dat "deprecated" verklaard en werkt het niet meer.
Je kent ze wel, die aankondigingen her en der van "vanaf versie XX support Firefox (of Chrome) deze veel gebruikte mode niet meer".
En daar moet je het dan maar mee doen. Heb je andere wensen of behoeften: PECH gehad.

Nu kun je natuurlijk nog wel met allerlei "truukjes" (javascript of rare CSS declaraties) hetzelfde bereiken, maar voor hetzelfde geld werkt dat volgende maand ook niet meer...

Het doel is niet zo zeer super security maar commercieel. Het geeft vertrouwelijke zakelijke informatie aan bezoekers die eerst langs een filter zijn gegaan. Waarbij men ook eerst aan moet klikken het in bescheiden kring te houden. In de hoop serieuzere klanten over te houden die daarna meer mogen weten.

Het gaat om nogal prijzige investeringen. Dat type klant/koper-hopelijk vergeet snel. Door steeds opnieuw het password te vragen, wil ik ze herinneren dat het geen publieke informatie is. Anders had het net zo goed open op Facebook gepost kunnen zijn. Tegelijk wordt natuurlijk zo een password gedeeld met een advocaat, een accountant en wat is er nog meer. Dat is ook geen probleem, vanzelfsprekend. Blijft dat password hangen in een cookie, dan gaat het effect weg dat men iets exclusiefs mag zien. Nu kan ik vanaf de site alle cookies deleten na bezoek. Behalve dat password cookie.

Implementeer een 2FA toegang. Kunnen browsers onthouden wat ze willen, maar je blijft een 2FA token nodig hebben.

Dat maakt het onnodig ingewikkeld voor wat ik wil.

Ik zal het concept even beter uitleggen. Voor dure en/of bekende dingen wil men nog wel eens zaken "in de stille verkoop" willen zetten. Bijvoorbeeld een jacht met een naam. Dat regelmatig gespot wordt. Je wil dan niet dat dat iedereen dat weet. Dan gaat men praten dat je moet verkopen. Of al het betrokken personeel gaat gelijk een andere baan zoeken. De conclusie dat er "daar blijkbaar wat mis is" wordt snel getrokken, en daarmee zakt de waarde.

Tegelijk wil je geen gratis excursies bieden. Je wilt niet weten hoeveel mensen proefritten willen in dure autos, gratis villa tours door het Gooi of eens op dat mooie jacht geweest zijn met veel fotos maken. Om dan daarna te zeggen dat ze er nog even over na gaan denken. Op zich hoort het er een beetje bij. Maar vervelend als je daardoor even een dag niet bereikbaar bent voor een ander die wél serieus is.

Daar zet je een keurig filter voor op. Zodat, mits een potentiële klant dat zelf wil, je al wat meer weet over hoe serieus het is. Een paar vrijblijvende vragen. Afhankelijk daarvan geef je dan een wachtwoord, zodat ik elk geval iets meer duidelijk wordt over wat er te koop staat. Zodat de potentiële koper beter kan bepalen of het inderdaad de moeite kan zijn om eens af te spreken. Maar wat wel vertrouwelijk is. Wat wat anders is dan geheim willen houden. Met 2FA, vingerafdruk en biometrie selfies. Dat is dan weer niet erg klantvriendelijk naar de potentiële klant toe, en ook niet nodig. Gewoon een redelijk simpel password is dan goed genoeg.

Wat ik dan enkel wil is dat de potentiële klant steeds opnieuw het wachtwoord in moet voeren. Om eraan te herinneren dat de informatie niet voor heel de wereld is. Of de verkoper zich zelfs kan terugtrekken. Het is enkel daarom dat ik niet wil dat de browser het password opslaat. Anders denkt de potentiële klant al snel dat heel de wereld het toch al weet en kan zien.

In elk cookie staat wel de expiration date. Maar dan moet ik in de WP core gaan rommelen. En dat verdwijnt dan weer met elke update, of Wordfence gaat op tilt.

Het doel is commercieel, niet om Fort Knox te beveiligen. Maar hoe flik je dat op een professionele manier?

Hier wat meer uitleg over wachtwoorden in WP.

https://passwordprotectwp.com/wordpress-password-protected-page-cookie/

2FA lijkt mij dan de beste oplossing. Je wilt ook niet dat mensen hun wachtwoord zelf moeten intypen, ook gezien mijn veel veiligere wachtwoordkluis Bitwarden juist de copy paste sneltoets heeft.

Qua veiligheid is het goed als mensen voor elke site een uniek lang wachtwoord aanmaken. Het wordt dan zeer gebruikersonvriendelijk als je mensen dwingt dit elke keer weer in te tikken. Ik gebruik wachtwoorden van > 30 karakters die ik niet onthoud per site en dan wil dat dit (semi)automatisch ingevuld wordt.

Je bent serieus van plan om met PHP en Wordpress vertrouwelijke zakelijke informatie beschikbaar te stellen via internet, waarbij je ook nog eens persoonlijke informatie gaat verwerken en opslaan? Dat kan een tranendal worden! (want PHP én Wordpress staan bekend om hun brakke kwaliteit en beveiligingsproblemen).

Dat heeft niets met PHP te maken, in elke taal kan je rotzooi schrijven. Maar idd zou ik ook adviseren geen Wordpress te kiezen wanner je vertrouwelijke gegevens verwerkt. Vooral wanneer je klakkeloos plugins van derde gaat gebruiken. Het is vragen om problemen.

Als je wilt afdwingen dat mensen regelmatig moeten inloggen dan zul je dat op de server moeten implementeren, sessies die na een (paar) uur verlopen, waarna de gebruiker opnieuw moet inloggen. Dat kan met een login cookie. Kijk eens welke modules er al voor WP beschikbaar zijn.

Of wat jij wilt is niet de juiste oplossing voor je probleem?
Je pakt het probleem verkeerd aan?

Juist iets wat 2FA eigenlijk doet.
Nog afgezien of je dit soort sites in WP zou moeten willen bouwen. Zeker als je al deze vragen hebt, weet ik niet of WP je juiste oplossing is voor deze site.

Dus zijn wachtwoord gaat hergebruiken?
Implementeer anders iets als SAML/oauth tegen een IPD aan. Maar de oplossing die jij eigenlijk bedenkt, is juist de verkeerde en maakt het juist onveiliger.

Of eigenlijk gebruik je dus de verkeerde software voor je oplossing?

Ben jij wel de juiste persoon op dit punt?
2FA?
De juiste software gebruiken?
Overlaten aan iemand die ver verstand van heeft?

Naast de gegeven tips is het wellicht ook goed:
1) te kijken naar je enrollment, want hoe voorkom je dat het wachtwoord niet alsnog ergens komt te staan?
2) op de pagina zelf duidelijk te blijven maken dat het om vertrouwelijke informatie gaat (want daar ging het om als ik het begrijp).

Er zijn wat opties met b.v. _newpassword te gebruiken als veldnamen, dan slaan browsers het niet goed op. Is wel aardig irritant in de praktijk.

Dat heeft alles met PHP te maken! (in niet elke programmeertaaltaal kan je alléén maar rotzooi schrijven).


Kijk aan, daarin zijn we het dus eens!

Daarom er ook soms zulke grote sites die PHP gebruiken? Wikipedia bijvoorbeeld? Facebook (staat los van privacy issues), Slack? Tweakers? Fok? En zo zijn er nog wel meer sites die het gebruiken en gewoon goed gebruiken.

Is het de beste taal, absoluut niet. Maar je kunt gewoon goed programmeren er in, helemaal met een goed framework er bij.

Wordpress zelf, is zelf niet verkeerd. De meeste issues zitten hem voornamelijk in de plugins.
Zou ik het adviseren of gebruiken: Absoluut niet.

Toch wel:
https://support.mozilla.org/en-US/kb/password-manager-remember-delete-edit-logins#w_disable-the-firefox-password-management-feature

Dat is iets dat de gebruiker instelt. De vraagsteller vraagt wat je op de server kan regelen om dit te bereiken, en niet alleen bij Firefox-gebruikers maar bij iedereen.

Ik weet het antwoord niet, daarvoor is mijn kennis te verouderd, ik ben een periode webontwikkelaar geweest in een tijd dat al fancy frameworks als Wordpress nog niet bestonden.

Maar vanuit dat perspectief is de eerste vraag die ik stel niet wat het framework voor modules en add-ons heeft, maar hoe de browser eigenlijk ermee omgaat. Daar zitten twee niveaus in:

1. De sessie-cookies die bij een sessie en dus bij de login horen. Die horen als cookie geen expiratiedatum/tijd te hebben. Het ontbreken daarvan geeft aan dat de cookies niet op de harde schijf bewaard moeten worden maar vervallen als de browser wordt afgesloten. Daarnaast hoort de server/webapplicatie een timeout voor de sessies te hebben: na zoveel minuten inactiviteit vervalt de sessie en moet de gebruiker opnieuw inloggen.

2. De faciliteit van webbrowsers om inloggegevens te bewaren en automatisch in te vullen. Die reageren, leert een vrij vluchtige zoekactie me, op formulieren die een <input type="password"> bevatten, een wachtwoordveld dus waar de gebruiker niet ziet wat hij/zij intypt. Daarvan hoop ik (maar ik heb het niet geverifieerd en ik heb er geen enkele ervaring mee omdat ik keepassxc als wachtwoordmanager gebruik en de browser zelf helemaal niets laat bewaren) dat een usernaam/wachtwoord aan een specifiek formulier op een specifieke pagina gekoppeld zijn. Keepassxc kijkt trouwens naar de titel van het browservenster. Je kan dan je doel bereiken door te zorgen dat waar de wachtwoord-onthouders van webbrowsers op reageren telkens anders te maken. Door ofwel de URL, ofwel id's of formuliernamen binnen de pagina, ofwel de titels van pagina's per keer anders te maken kan je, als de browser inderdaad op dat niveau dingen bewaart, forceren dat het voor de browser telkens iets is dat die nooit eerder is tegengekomen en waar bewaarde wachtwoorden niets mee te maken hebben.

Er is, als je op dat niveau dingen kan aansturen, vast wel wat voor elkaar te krijgen. Je hebt alleen geen enkele garantie dat hoe browsers nu werken ook is hoe browsers straks werken. Dit is geen onderdeel van de een of andere webstandaard waarop je kan vertrouwen. Dat betekent dat, als je zoiets doet, je voortdurend in de gaten moet blijven houden of de oplossing nog steeds werkt. En dan worden er vermoedelijk dingen gedaan die Wordpress of de gebruikte plugins helemaal niet ondersteunen. Dan werk je, zoals de vraagsteller ook al aangeeft, met wijzigingen die bij elke update overschreven worden. Da's al met al geen kenmerk van goede oplossingen, dat is wat we getruct noemen.

Als er geen Wordpress-plugin bestaat die dit expliciet regelt denk ik daarom dat de vraagsteller de oplossing in een heel andere hoek zoeken moet: niet in voor elkaar krijgen wat die in gedachten heeft maar in een heel andere benadering van het probleem, met oplossingen op een ander niveau. Hoe dat er dan uitziet? Geen idee, vrees ik. Ik heb vooral het idee dat de huidige benadering wel eens een dood spoor kan blijken te zijn.

Technological debt. Goedkoop (is uiteindelijk duurkoop; kijk maar naar de mobiele weergave van security.nl).


PHP idem (absoluut niet gebruiken).

Je vindt het onnodig ingewikkeld maar je serveert de gebruiker wel vertrouwelijke informatie ???????????

Ik begrijp nog steeds niet waarom 2fa niet een optie is. Vanuit de potentiële klant bekeken juist prachtig: voelt lekker veilig en geeft nog eens extra dat gevoel van exclusiviteit. Marketingtechnisch lijkt me dat prima.

Ben je technisch niet onderlegt,besteed de implementatie uit. En denk na over privacy: hoe verwerk je zo min mogelijk benodigde gegevens veilig?

Ik denk dat de TS een heel veel beter beeld heeft van de bereidheid tot ongemak van klanten voor luxe jachten dan jij.

De jachtzoekers zijn helemaal niet erg op zoek naar geheim en veiligheid .
Het zijn alleen de jacht-verkopers die _wel_ alle enigszins serieus te nemen klanten willen trekken , maar _niet_ aan de grote klok hangen dat ze hun jacht wegdoen . (en ook geen uitje voor armoedzaaiers 'mooi weer, even jachtje kijken' willen worden)

Dat bijt elkaar - en dus moet TS proberen om de jacht-zoekers het enigszins moeilijk te maken om toegang niet al te hard te laten lekken . Terwijl de jachtzoekers geen groot belang heeft om zuinig te zijn op de toegang , en ook niet weggepest moet worden , want uiteindelijk moet die boot wel verkocht worden.

Ik begrijp heel goed dat een 2FA proces - zeker als je geen duurzame relatie hebt - dan echt niet welkom is.

@TS - heb je ook overwogen om de passwords heel frequent te laten cyclen - gewoon automatisch, en dan mailen/appen/txten naar de bezoeker ?

Het hoeft dan geen lang superpassword te zijn. Je zou zelfs een nieuwe 4-cijfer pin na elke toegang (of elke week ? dag ?) kunnen laten sturen .

Icm met een lockout/update na 5 foute pogingen is dat ook geen enorm security risico , en het haalt de motivatie om op te slaan wel weg.

Daar noem je meteen al weer 2 zaken die waarschijnlijk lijnrecht tegenover elkaar staan: authenticatie uitbesteden
en het veilig verwerken van gegevens garanderen.
Het is lekker makkelijk om hier te roepen wat ie allemaal fout doet, maar wat voor oplossing hij ook zal kiezen, er zal
een bepaalde groep hier met hoongelach op reageren.

Dit beschrijft heel goed de problematiek van beveiliging. Beveiliging geeft ongemak en schrikt gebruikers af, en de
belangen liggen op verschillende plaatsen. Sommige mensen hier schijnen te denken dat de beste en meest uitgebreide
beveiliging altijd de beste is in iedere situatie, maar dat is duidelijk niet het geval.
Laat dit een les zijn voor velen!