hidden variable

[Verwijderd]

Het gaat om een login pagina voor webmail.
Op de eerste pagina vul je in je domeinnaam, gebruikersnaam en wachtwoord.

Deze gegevens stuurt ie door naar de 2de pagina.

Van de domeinnaam bekijkt het script het ip nummer en van het ip nummer de hostname om zo op de juiste server in te loggen.

Het probleem is nu dat het doorsturen naar de 2de pagina ook het wachtwoord gewoon in plain-text gebeurt. Ofwel, deze staat gewoon in de broncode.

Is het mogelijk om deze gegevens niet te laten zien in de broncode?
Via ssi is het niet mogelijk aangezien het een php bestand is.

stukje van pagina 1

PHP:

      <TR>
         <TD ALIGN=right>E-mail Wachtwoord:</TD>
         <TD WIDTH="*" ALIGN=left>
            <INPUT TYPE=PASSWORD NAME="secretkey">
         </TD>
      </TR>

stukje van pagina 2 wat ie eigenlijk moet verbergen

PHP:

echo "<FORM ACTION='http://".$hostname."/redirect.php' METHOD='POST' NAME=f>
<INPUT TYPE=HIDDEN NAME='login_username' VALUE='".$login_username."'>
<INPUT TYPE=HIDDEN NAME='login_domain' VALUE='".$login_domain."'>
<INPUT TYPE=HIDDEN NAME='secretkey' VALUE='".$secretkey."'>

Het volgende is dus wat je in de broncode kan lezen:

FORM ACTION='http://webmail.dejuisteserver.nl/src/redirect.php' METHOD='POST' NAME=f>
<INPUT TYPE=HIDDEN NAME='login_username' VALUE='testuser'>
<INPUT TYPE=HIDDEN NAME='login_domain' VALUE='testtttt.nl'>
<INPUT TYPE=HIDDEN NAME='secretkey' VALUE='ditishetwachtwoord'>

[ Voor 15% gewijzigd door Verwijderd op 22-05-2003 12:30 ]

[Willem]

.htaccess ?

Simpele username/password

[Bosmonster]

Of MD5 het wachtwoord en check deze vervolgens. Dan hoef je alleen de MD5 hash in de pagina te verwerken.

[RM-rf]

Bosmonster schreef op 22 May 2003 @ 12:36:
Of MD5 het wachtwoord en check deze vervolgens. Dan hoef je alleen de MD5 hash in de pagina te verwerken.

dat zou geheel onlogisch en nog slechter zijn, immers dan maak je je authorisatie op een direct al ge-md5-de string en aldus kan iemand die de hash weet al direct zelf inloggen op de applicatie (dan heeft hashen zelf ook weinig zin meer).

mijn gok zou zijn om met serverside seesions te werken, na de eerste submit de verstuurde variabelen serverside op te slaan en enkel een sessionID te gebruiken waarmee je de eerder verstuurde variabelen weer kunt opvragen, en tevens een verdomd korte timeout te zetten (15mins ofzoiets)

overigens is het hele idee om een login te versturen naar pagina X die dat dan toepast om in te loggen op pagina Y een verkeerde methode, die de meeste gebruikers absoluut uit de weg moeten gaan;
iedere corruptie bij server X zorgt ervoor dat ook de inlog op server Y gesniffed kan worden;
ik zou enkel de inlognaam toestaan vooraf te definieren, terwijl het passwoord absoluut enkel naar de betreffende server zelf gestuurd zou mogen worden, niet naar intermediates
(bedenk alleen al hoe ergerlijk en makkelijk te misbruiken zoiets als password-herinnering icm auto-complete forms is, dat is eenvoudig te misbruiken met wat javascript en een form dat je in een hidden layer zet en direct laat submitten)

[ Voor 33% gewijzigd door RM-rf op 22-05-2003 12:58 ]

[Verwijderd]

.htaccess gaat niet echt lukken volgens mij, dan zou men elke keer een login schermpje te zien krijgen......

MD5 is denk ook geen optie. Normaal kan je al inloggen op webmail. Wat mijn script doet is ook inloggen op webmail maar op server waar ook hun domeinnaam op staat.


RM-rf, jouw optie is misschien een goede optie, maar zo'n ongelooflijke php kenner ben ik ook weer niet. Denk niet dat ik dat voor mekaar ga krijgen...


Mooiste zou iets zijn als ssi.
Dit staat bijvoorbeeld in de html code van een andere pagina:
<!--#include virtual="/cgi-bin/traxis/traxis-counter.cgi?site=hiero"-->

Mocht je dan in de broncode kijken, zie je niets meer van dat stukje code terug.

[ Voor 43% gewijzigd door Verwijderd op 22-05-2003 12:58 ]

[SchizoDuckie]

Verwijderd schreef op 22 mei 2003 @ 12:54:
.htaccess gaat niet echt lukken volgens mij, dan zou men elke keer een login schermpje te zien krijgen......

ow heb ik nog nooit last van gehad eigenlijk...

[Bosmonster]

RM-rf schreef op 22 May 2003 @ 12:53:
[...]


dat zou geheel onlogisch en nog slechter zijn, immers dan maak je je authorisatie op een direct al ge-md5-de string en aldus kan iemand die de hash weet al direct zelf inloggen op de applicatie (dan heeft hashen zelf ook weinig zin meer).

Dat snap ik niet.. hij zet nu het wachtwoord gewoon in de pagina. Alles beter dan dat. Zijn vraag was dus ook simpelweg hoe die het wachtwoord uit de source kon houden.

Als je het mij vraagt is die hele tweede pagina nutteloos. Je kunt toch direct nadat iemand zijn gegevens heeft ingevoerd inloggen? Daar hoeft toch niet een redirect met een tweede pagina in te zitten?

[Verwijderd]

2de pagina is voornamelijk om de domeinnaam om te zetten naar ip, waarna deze weer omgezet word naar hostname.
In de orginele inlogpagina staat namelijk webmail.$hostname.nl

[RM-rf]

Bosmonster schreef op 22 May 2003 @ 13:00:

Dat snap ik niet.. hij zet nu het wachtwoord gewoon in de pagina. Alles beter dan dat. Zijn vraag was dus ook simpelweg hoe die het wachtwoord uit de source kon houden.

code:

onveilige code:
login-pagina > 
pagina met 'password' hidden in code 
     (password = 'blah') > 
login-exec: 
   'SELECT userID WHERE username = '$username' AND password = 'md5('$password')'

tegenover

bosmonster optie:
login-pagina > 
pagina met 'password' md5-ed in code  
       (password = '73693361d467266b627c4e06811b9181') > 
login-exec: 
   'SELECT userID WHERE username = '$username' AND password = '$md5_password'

het enige verschil is dat in de tweede optie het wachtwoord er 'meolijk uitziet', maar iemand die de hash weet (ofwel via een gehackede database, ofwel door de webpage ergens in een cache te vinden of te sniffen) kan via de webinterface direkt inloggen:

het enige voordeel is dat het wachtwoord erg moeilijk te onthouden is, en dus exact genoteerd moet worden, het nadeel is echter dat je zonder verdere hash het password checked en het te checken password dus exact overeen komt met de variabele in de db, ergo; geen encryptie op de check zelf.

in die zin vind ik de tweede optie zelfs nog minder veilig dan de eerste (enkel meer 'schijn'-veilig).

overigens:
session-management zit standaard in php, zoek eens op 'session' op php.net en je vind standaard functies;
enige nadeel hiervan is dat de sessions van php worden opgeslagen in platte text-files in een directory readable door de webserver-deamon en op een publieke server zeker niet veilig zijn.

Verwijderd schreef op 22 May 2003 @ 13:17:
2de pagina is voornamelijk om de domeinnaam om te zetten naar ip, waarna deze weer omgezet word naar hostname.
In de orginele inlogpagina staat namelijk webmail.$hostname.nl

ehm, is dat niet een kwestie van juist beheer over virtual domains (en DNS) en moet je dat helemaal niet oplossen door allerlei plakbandjes over de weg die de gebruiker aflegt te plakken:
er bestaat weinig kluizen die afsluitbaar zijn met cellofaan, oondanks dat dit veel gemak biedt bij het openen en sluiten van de deur en ook voorkomt dat mensen hun kluiscode of sleutel verliezen.

[ Voor 28% gewijzigd door RM-rf op 22-05-2003 13:34 ]

[Verwijderd]

Over het laatste stukje.
Het inloggen op webmail is nu al gewoon mogelijk, maar nu logt men altijd in op server 3, ook al staat de domeinnaam op server 4 of 5.

Het enige wat ik hiermee wil bereiken is om de belasting op server 3 te verkleinen en zo te verdelen over de andere servers. Daarnaast is het ook makkelijker en sneller om op je eigen server in te loggen.

[RM-rf]

Verwijderd schreef op 22 May 2003 @ 13:44:
Over het laatste stukje.
Het inloggen op webmail is nu al gewoon mogelijk, maar nu logt men altijd in op server 3, ook al staat de domeinnaam op server 4 of 5.

Het enige wat ik hiermee wil bereiken is om de belasting op server 3 te verkleinen en zo te verdelen over de andere servers. Daarnaast is het ook makkelijker en sneller om op je eigen server in te loggen.

je kunt toch gewoon webmail.domeinnaam.nl naar een ander IP laten verwijzen dan der rest van *.domeinnaam.nl, kwestie van wat onderzoek doen naar DNS-binding en virtual hosts.
het 'load'-balancing-voordeel betwijfel ik ten zeerste, een login is in vergelijking met een mail-applicatie zelf natuurlijk een minmale belasting, zeker als de request alsnog doorgestuurd wordt.

alsof driemaal linksafslaan een versnelde vorm is van 1 keer rechtsaf slaan.
Het is volgens mij complete onzin zelf om load-balancing te laten doen met PHP, daarvoor is PHP als module binnen een webserver een veels te ver embedded library:

kijk liver of je de mail-applicatie op 1 server, of de mailserver zelf niet beter kunt 'balancen'.
Als je werkelijk zoiets wilt uitvoeren loop je risico tot koning van de PHP-Aapjes-Rots verkozen te worden.

[ Voor 5% gewijzigd door RM-rf op 22-05-2003 14:12 ]