DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Omdat de document root van de webserver blijkbaar niet hetzelfde is als de homefolder van de FTP-user.quote:Op maandag 10 oktober 2011 09:19 schreef boem-dikkie het volgende:
[..]
Dat snap ik wel. Ik snap alleen niet waarom ik via HTTP niet bij die files kan en via FTP wel.
Ik heb het uitgevogeld. De map /photo/ waar de foto's in staan die ik wil bereiken is beheerd door een programma Photo Station op de NAS die als webserver dient. Hierdoor is het dus onmogelijk om zonder het daadwerkelijke Photo Station die foto's op te halen en neer te plempen op een andere website..
Weten jullie of er misschien een functie is waarmee ik gemakkelijk in kan loggen op die FTP (nas), elke 12 uur check op updates en dan alles automatisch kopieer naar de FTP waar ook de website staat die de foto's moet laten zien?
Weten jullie of er misschien een functie is waarmee ik gemakkelijk in kan loggen op die FTP (nas), elke 12 uur check op updates en dan alles automatisch kopieer naar de FTP waar ook de website staat die de foto's moet laten zien?
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Je zou de standaard FTP functies van PHP kunnen gebruiken en het script dmv een cronjob elke 12 uur laten uitvoeren.quote:Op dinsdag 11 oktober 2011 11:32 schreef boem-dikkie het volgende:
Ik heb het uitgevogeld. De map /photo/ waar de foto's in staan die ik wil bereiken is beheerd door een programma Photo Station op de NAS die als webserver dient. Hierdoor is het dus onmogelijk om zonder het daadwerkelijke Photo Station die foto's op te halen en neer te plempen op een andere website..
Weten jullie of er misschien een functie is waarmee ik gemakkelijk in kan loggen op die FTP (nas), elke 12 uur check op updates en dan alles automatisch kopieer naar de FTP waar ook de website staat die de foto's moet laten zien?
Zie ook: http://www.php.net/manual/en/ref.ftp.php
xdebug+netbeans
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Kan misschien aan mij liggen, maar kan het nergens vinden.
Mijn Zend_Soap_Client spuugt als die klaar is met de functie getLastRequest er netjes een xml uit. Alles gaat eigenlijk ook gewoon goed. Alleen de gehele XML wordt getoont op 1 regel, ipv netjes met linebreaks etc.
Iemand ideeën?
Mijn Zend_Soap_Client spuugt als die klaar is met de functie getLastRequest er netjes een xml uit. Alles gaat eigenlijk ook gewoon goed. Alleen de gehele XML wordt getoont op 1 regel, ipv netjes met linebreaks etc.
Iemand ideeën?
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
Ik ben bezig met een klein artikel waardering systeem.
Op een pagina kan een gebruiker aangeven of die pagina 'nuttig' was (dit is ja/nee, wat in de database wordt neergezet als 1/0).
Nu wil ik vanuit een soort van beheer systeem dit uitlezen.
De structuur is heel simpel:
De tabel met artikelen
De tabel met feedback
Ik heb met een simpele query met een left join de tabellen aan elkaar, alleen wil ik het percentage weten welke op "ja" (=1) hebben geklikt
Dit is in het kort de query zoals ik die nu heb (ik heb nog wat aliassen toegevoegd, maar is niet relevant). De query werkt zover. Van ieder artikel, krijg ik daarnaast het aantal waarderingen. Nu wil ik weten hoeveel van die waarderingen dus 1 zijn. Dit krijg ik niet voor elkaar. Dacht zelf in de richting van
Wie kan me helpen? Kan het eventueel wel in PHP doen, maar het is mooier en scheelt code als het direct met MySQL kan.
Op een pagina kan een gebruiker aangeven of die pagina 'nuttig' was (dit is ja/nee, wat in de database wordt neergezet als 1/0).
Nu wil ik vanuit een soort van beheer systeem dit uitlezen.
De structuur is heel simpel:
De tabel met artikelen
| 1 2 | article id, text, date |
De tabel met feedback
| 1 2 | feedback id, article_id, choice, date |
Ik heb met een simpele query met een left join de tabellen aan elkaar, alleen wil ik het percentage weten welke op "ja" (=1) hebben geklikt
| 1 | SELECT id, COUNT(feedback.id) AS aantal FROM article LEFT JOIN feedback ON (article.id = feedback.article_id) GROUP BY id |
Dit is in het kort de query zoals ik die nu heb (ik heb nog wat aliassen toegevoegd, maar is niet relevant). De query werkt zover. Van ieder artikel, krijg ik daarnaast het aantal waarderingen. Nu wil ik weten hoeveel van die waarderingen dus 1 zijn. Dit krijg ik niet voor elkaar. Dacht zelf in de richting van
| 1 | COUNT(feedback.choice = 1 / COUNT(feedback.id) * 100) AS percentage |
Wie kan me helpen? Kan het eventueel wel in PHP doen, maar het is mooier en scheelt code als het direct met MySQL kan.
Denormaliseer en stop het aantal in de tabel article. Anders zoek je:
of simpeler:
| 1 | (SUM(IF(feedback.choice = 1,1,0)) / COUNT(*) * 100) AS percentage |
| 1 | (SUM(feedback.choice) / COUNT(*) * 100) AS percentage |
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
http://forums.mysql.com/read.php?52,134684,134741#msg-134741quote:Op donderdag 13 oktober 2011 14:58 schreef remi1986 het volgende:
Ik ben bezig met een klein artikel waardering systeem.
Op een pagina kan een gebruiker aangeven of die pagina 'nuttig' was (dit is ja/nee, wat in de database wordt neergezet als 1/0).
Nu wil ik vanuit een soort van beheer systeem dit uitlezen.
De structuur is heel simpel:
De tabel met artikelen
[ code verwijderd ]
De tabel met feedback
[ code verwijderd ]
Ik heb met een simpele query met een left join de tabellen aan elkaar, alleen wil ik het percentage weten welke op "ja" (=1) hebben geklikt
[ code verwijderd ]
Dit is in het kort de query zoals ik die nu heb (ik heb nog wat aliassen toegevoegd, maar is niet relevant). De query werkt zover. Van ieder artikel, krijg ik daarnaast het aantal waarderingen. Nu wil ik weten hoeveel van die waarderingen dus 1 zijn. Dit krijg ik niet voor elkaar. Dacht zelf in de richting van
[ code verwijderd ]
Wie kan me helpen? Kan het eventueel wel in PHP doen, maar het is mooier en scheelt code als het direct met MySQL kan.
Zoiets ?
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Super, dit is precies wat ik zocht!quote:
Denormaliseer en stop het aantal in de tabel article. Anders zoek je:
[ code verwijderd ]
of simpeler:
[ code verwijderd ]
Vraag aan de experts! 
Ik wil een site aanpassen qua 'wachtwoorden'. Nu gebruikt de site standaard MD5 (die met een simpele rainbowtable kan gehacked worden). Nu wil ik deze aanpassen en omzetten naar sha oid.
Alleen is het niet mogelijk om het originele wachtwoord te achterhalen, hoe zou ik deze user base toch beter kunnen beschermen.
Zelf zit ik te denken aan dit.
VAN DB -> MD5(PASS) -> SHA1(MD5 - SALT - MD5) -> NAAR DB
Idee of zit ik verkeerd te denken?
Ik wil een site aanpassen qua 'wachtwoorden'. Nu gebruikt de site standaard MD5 (die met een simpele rainbowtable kan gehacked worden). Nu wil ik deze aanpassen en omzetten naar sha oid.
Alleen is het niet mogelijk om het originele wachtwoord te achterhalen, hoe zou ik deze user base toch beter kunnen beschermen.
Zelf zit ik te denken aan dit.
VAN DB -> MD5(PASS) -> SHA1(MD5 - SALT - MD5) -> NAAR DB
Idee of zit ik verkeerd te denken?
Just say hi!
Ik had hetzelfde probleem en heb het ook ongeveer zo opgelost, maar dan met sha512.quote:Op vrijdag 14 oktober 2011 09:59 schreef Chandler het volgende:
Vraag aan de experts!
Ik wil een site aanpassen qua 'wachtwoorden'. Nu gebruikt de site standaard MD5 (die met een simpele rainbowtable kan gehacked worden). Nu wil ik deze aanpassen en omzetten naar sha oid.
Alleen is het niet mogelijk om het originele wachtwoord te achterhalen, hoe zou ik deze user base toch beter kunnen beschermen.
Zelf zit ik te denken aan dit.
VAN DB -> MD5(PASS) -> SHA1(MD5 - SALT - MD5) -> NAAR DB
Idee of zit ik verkeerd te denken?
Ik weet niet of er ook nadelen zitten aan 2x hashen, behalve dan dat het ietsje langer duurt.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Zorg dat de salt per user uniek is, één keer de MD5 in de SHA is wel voldoende.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Hoe bedoel je dat de salt per user uniek moet zijn? doel je dan op gebruik van USER ID, Registratie datum of andere gegevens?
Just say hi!
Beter kan je als iemand inlogt dit proces uitvoeren. Dus als de gegevens van het inlog formulier kloppen, en de user zijn password is nog niet aangepast naar de nieuwe hash, gewoon met een tijdelijke column in de user tabel die default op false staat checken, dan een update doen op de password column.
Dus waar je normaal gesproken een sessie aanmaakt bij de login, ook nog even het wachtwoord updaten in de db als dit nog niet is gedaan. Een minder gebruikersvriendelijke, maar wel snellere optie, is om gewoon iedereen zijn wachtwoord te resetten en een mail sturen dat ze hun wachtwoord opnieuw moeten instellen of zelf een nieuw random wachtwoord aan iedere gebruiker sturen.
Dus waar je normaal gesproken een sessie aanmaakt bij de login, ook nog even het wachtwoord updaten in de db als dit nog niet is gedaan. Een minder gebruikersvriendelijke, maar wel snellere optie, is om gewoon iedereen zijn wachtwoord te resetten en een mail sturen dat ze hun wachtwoord opnieuw moeten instellen of zelf een nieuw random wachtwoord aan iedere gebruiker sturen.
Op tweakers.net hebben ze op het moment een overgangsperiode. Ze zijn overgegaan naar een nieuwe manier van hashen. De eerste keer dat je inlogt wordt dat nog geconfirmeerd met de oude hash en wordt direct een nieuwe hash aangemaakt en de oude verwijderd (neem ik aan).quote:
Vraag aan de experts!
Ik wil een site aanpassen qua 'wachtwoorden'. Nu gebruikt de site standaard MD5 (die met een simpele rainbowtable kan gehacked worden). Nu wil ik deze aanpassen en omzetten naar sha oid.
Alleen is het niet mogelijk om het originele wachtwoord te achterhalen, hoe zou ik deze user base toch beter kunnen beschermen.
Zelf zit ik te denken aan dit.
VAN DB -> MD5(PASS) -> SHA1(MD5 - SALT - MD5) -> NAAR DB
Idee of zit ik verkeerd te denken?
Maar je kunt idd ook dubbel hashen, lijkt me weinig mis mee. En voor de salt kun je idd vanalles gebruiken wat je opslaat over een user: gebruikersnaam, registratiedatum, desnoods met een random-string generator voor iedere user een speciale saltstring maken en opslaan in je users tabel.
Zowel SHA als MD5 zijn niet veilig. Rainbow tables is niet je grootste probleem. Je grootste probleem is dat zelfs SHA te snel is. GPU bruteforcen is tegenwoordig de manier waarop deze passwords gekraakt worden, niet d.m.v. rainbow tables want die zijn te verslaan met een simpele salt.
Ter info:
http://chargen.matasano.c(...)to-know-about-s.html
Conclusie: je moet bcrypt gebruiken, en geen MD5 of SHA.
http://stackoverflow.com/(...)ing-passwords-in-php
Ter info:
http://chargen.matasano.c(...)to-know-about-s.html
Conclusie: je moet bcrypt gebruiken, en geen MD5 of SHA.
http://stackoverflow.com/(...)ing-passwords-in-php
Dat laatste heb je natuurlijk geen hol aan. Als ze je userdatabase hebben, hebben ze ook je salts. Kun je net zo goed de username als een van de salts gebruiken.quote:
Maar je kunt idd ook dubbel hashen, lijkt me weinig mis mee. En voor de salt kun je idd vanalles gebruiken wat je opslaat over een user: gebruikersnaam, registratiedatum, desnoods met een random-string generator voor iedere user een speciale saltstring maken en opslaan in je users tabel.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
bcrypt is overkill. Een sterke dynamische salt voor elke user met sha(512) is voldoende voor de meesten. Zodra je hele database kan worden ingekeken ben je een stuk sterker met een dynamisch stuk salt.quote:
Zowel SHA als MD5 zijn niet veilig. Rainbow tables is niet je grootste probleem. Je grootste probleem is dat zelfs SHA te snel is. GPU bruteforcen is tegenwoordig de manier waarop deze passwords gekraakt worden, niet d.m.v. rainbow tables want die zijn te verslaan met een simpele salt.
Ter info:
http://chargen.matasano.c(...)to-know-about-s.html
Conclusie: je moet bcrypt gebruiken, en geen MD5 of SHA.
http://stackoverflow.com/(...)ing-passwords-in-php
Dat laatste heb je natuurlijk geen hol aan. Als ze je userdatabase hebben, hebben ze ook je salts. Kun je net zo goed de username als een van de salts gebruiken.
Dan hebben ze een stukje van je salt. Ze weten niet hoe vaak jij die nog achterstevoren, binnenstebuiten, base64 en md5't. En wat je nog meer aan gegevens gebruikt.quote:
Dat laatste heb je natuurlijk geen hol aan. Als ze je userdatabase hebben, hebben ze ook je salts. Kun je net zo goed de username als een van de salts gebruiken.
En bovendien het hele idee van een salt is dat het onmogelijk wordt om hashes te vergelijken. Daarvoor boeit het nieteens of de aanvaller weet hoe de salt eruit ziet. Als ze maar uniek zijn.
Ik zeg niet dat je niet moet salten. Ik bedoel alleen dat een oplossing puur op MD5 en/of SHA een beetje te wensen overlaat omdat tegenwoordig passwords gewoon gebruteforced worden. Natuurlijk is bcrypt voor een simpele site misschien wat overkill, maar bcrypt is tenminste redelijk future-proof.quote:Op vrijdag 14 oktober 2011 10:24 schreef Ouqz het volgende:
bcrypt is overkill. Een sterke dynamische salt voor elke user met sha(512) is voldoende voor de meesten. Zodra je hele database kan worden ingekeken ben je een stuk sterker met een dynamisch stuk salt.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Is het idee van salten niet dat bruteforcen weinig zin heeft en dat daarom MD5 of SHA1 opeens helemaal niet zo brak meer zijn?quote:
[..]
Ik zeg niet dat je niet moet salten. Ik bedoel alleen dat een oplossing puur op MD5 en/of SHA een beetje te wensen overlaat omdat tegenwoordig passwords gewoon gebruteforced worden.
Je bescherm je toch wel tegen bruteforcen neem ik aan?
Na X aantal mislukte pogingen binnen Y periode is gewoon geen toegang.
Na X aantal mislukte pogingen binnen Y periode is gewoon geen toegang.
Het gaat er voornamelijk om wat je doet als je hele usertabel uitlekt.quote:
Je bescherm je toch wel tegen bruteforcen neem ik aan?
Na X aantal mislukte pogingen binnen Y periode is gewoon geen toegang.
Zie daarvoor weer de reactie van Koepadquote:Op vrijdag 14 oktober 2011 10:36 schreef Tijn het volgende:
[..]
Het gaat er voornamelijk om wat je doet als je hele usertabel uitlekt.
quote:Op vrijdag 14 oktober 2011 10:28 schreef Koepad het volgende:
[..]
Dan hebben ze een stukje van je salt. Ze weten niet hoe vaak jij die nog achterstevoren, binnenstebuiten, base64 en md5't. En wat je nog meer aan gegevens gebruikt.
En bovendien het hele idee van een salt is dat het onmogelijk wordt om hashes te vergelijken. Daarvoor boeit het nieteens of de aanvaller weet hoe de salt eruit ziet. Als ze maar uniek zijn.
Nee, bruteforcen kun je altijd doen. salten doe je zodat als iemand je database te pakken krijgt, hij niet simpelweg de hashes kan vergelijken met een andere database met hashes die hij gemaakt heeft met zijn "check wie jou geblokkeerd heeft op msn"-website.quote:
[..]
Is het idee van salten niet dat bruteforcen weinig zin heeft en dat daarom MD5 of SHA1 opeens helemaal niet zo brak meer zijn?
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |