[alg] Slechtste programmeervoorbeelden deel 4

[Styxxy]

Deze verdient ook wel een plaatsje in dit topic:


(ja, dat is een alert)

En het grappige is dat de website dus perfect werkt...

[ Voor 14% gewijzigd door Styxxy op 31-07-2012 18:18 ]

[Webgnome]

Styxxy schreef op dinsdag 31 juli 2012 @ 18:18:
Deze verdient ook wel een plaatsje in dit topic:

[afbeelding]
(ja, dat is een alert)

En het grappige is dat de website dus perfect werkt...

En dat is een slecht programmeer voorbeeld omdat?

[Firesphere]

Webgnome schreef op dinsdag 31 juli 2012 @ 19:46:
[...]


En dat is een slecht programmeer voorbeeld omdat?

De programmeur heeft bedacht dat Opera een verouderde browser is?

Geen code, wel slecht.

[Styxxy]

Webgnome schreef op dinsdag 31 juli 2012 @ 19:46:
[...]
En dat is een slecht programmeer voorbeeld omdat?

Omdat er duidelijk browser en versie "sniffing" gedaan wordt (en dat moet je programmeren,yes really). Daarbij is het gewoon erg onprofessioneel om op de frontpage zo'n JavaScript alert te tonen... Overigens, slecht hoeft niet per se spaghetti code te zijn, dit soort zaken horen even goed in deze boot thuis.

[BM]

Waarschijnlijk whitelisting ipv blacklisting, geloof dat ik de voorkeur zou geven aan het laatste

[Xantios]

Firesphere schreef op dinsdag 31 juli 2012 @ 19:47:
[...]

De programmeur heeft bedacht dat Opera een verouderde browser is?

Geen code, wel slecht.

Opera is geen verouderde browser, maar wel een bitch van een ding...
Begrijp me niet verkeerd, ik zeg niet dat het een slechte browser is, vind het persoonlijk niet de fijnste, maar dat is smaak!

Wat me echter wel beetje tegenzit aan Opera is, dat het zo weinig gebruikt wordt ( kijk maar naar het markt aandeel) dat een hoop site's er simpelweg geen rekening mee houden ( Ik vind dat niet heel gek )

Dat ie een Javascript alert gebruikt vind ik dan wel weer een goed voorbeeld van hoe het NIET moet..
Javascript is leuk voor de extra's, maar je site moet simpelweg ook werken ZONDER javascipt.

[Styxxy]

Xantios schreef op dinsdag 31 juli 2012 @ 20:44:
[...]
Opera is geen verouderde browser, maar wel een bitch van een ding...
Begrijp me niet verkeerd, ik zeg niet dat het een slechte browser is, vind het persoonlijk niet de fijnste, maar dat is smaak!

Oké, ik probeer je niet verkeerd te begrijpen, maar wat maakt het een "bitch"? Oké, het wordt weinig gebruikt, maar al bij al vertoont Opera geen rare kuren. Tenzij je erg uitgebreide (en JavaScript intensieve) webapplicaties (zoals gmail, ...) gaat maken, is het echt niet nodig om zo hard te sniffen.

[Onbekend]

Xantios schreef op dinsdag 31 juli 2012 @ 20:44:
Wat me echter wel beetje tegenzit aan Opera is, dat het zo weinig gebruikt wordt ( kijk maar naar het markt aandeel) dat een hoop site's er simpelweg geen rekening mee houden ( Ik vind dat niet heel gek )

Hebben beide elementen niet met elkaar te maken? De weergave van een website (die netjes volgens html5 en css3 zijn geschreven) zou tussen de browsers onderling niet uit moeten maken. De GUI moet een gebruiker trekken om een bepaalde browser te gaan gebruiken, want de weergave zou identiek moeten zijn.

Als een website op Firefox goed werkt, dan ga ik die niet nog eens in Chrome testen en verwacht ik dat die in andere browsers ook goed werkt. (Ik test hem wel in IE aangezien veel mensen niet weten dat er ook nog iets anders dan IE bestaat. )

[roy-t]

Ik gebruik Opera als primaire browser en dat gaat bijna altijd. Maar vandaag heb ik er dan wel weer last van. Het nieuwe Outlook.com rendered correct maar er is niets aan te klikken ... ARG frustraties. Achja zo heb je met elke browser wel een site die het niet doet.

[Caelorum]

Tja, met 1000+ errors aangegeven door de developer console van opera kan je dat ook wel verwachten

[ Voor 8% gewijzigd door Caelorum op 31-07-2012 23:38 ]

[Styxxy]

roy-t schreef op dinsdag 31 juli 2012 @ 23:11:
Ik gebruik Opera als primaire browser en dat gaat bijna altijd. Maar vandaag heb ik er dan wel weer last van. Het nieuwe Outlook.com rendered correct maar er is niets aan te klikken ... ARG frustraties. Achja zo heb je met elke browser wel een site die het niet doet.

Microsoft trekt zich spijtig genoeg niets aan van Opera . Bijvoorbeeld de Bing Maps API (JavaScript) wordt officieel niet ondersteund en als je de voorbeelden volgt, werkt het inderdaad niet. Ik heb gevonden om bepaalde kleine zaken aan te passen (HTML en CSS) waardoor het plots wel allemaal werkt. Ik gebruik veel MS producten en ben er ook tevreden over, maar soms vind ik MS toch maar een prutbedrijf.

[Xantios]

Styxxy schreef op dinsdag 31 juli 2012 @ 21:20:
[...]

Oké, ik probeer je niet verkeerd te begrijpen, maar wat maakt het een "bitch"? Oké, het wordt weinig gebruikt, maar al bij al vertoont Opera geen rare kuren. Tenzij je erg uitgebreide (en JavaScript intensieve) webapplicaties (zoals gmail, ...) gaat maken, is het echt niet nodig om zo hard te sniffen.

Het vertoont inderdaad geen rare kuren, ik zou bijna zeggen dat het "te goed" is, over het algemeen houd Opera zich echt PRECIES tot op de punt aan de standaard, en in theorie is dat een geschenk uit de hemel, in de praktijk renderen site's gewoon niet altijd lekker en kun je Opera dus nooit als primaire browser gebruiken, en zul je altijd nog een 2e browser moeten gaan zoeken voor de sites die zich niet aan de standaarden houden.

dus het probleem is vooral dat Opera zichzelf uit de markt stoot door zijn succes eigenlijk, maar daardoor is het dus wel een beetje een bitch om voor te willen coden...

Het is niet dat het technisch slecht is, het is gewoon niet altijd lekker compatibel.

Dus, uhm... ja... lange post is best lang ( voor deze tijd van het jaar ( 02:24 ))

[Relief2009]

Ik vind het gezeik op MS wel heel makkelijk. Ik ga me toch afvragen of Opera iets niet fout doet. Ik hoor al vaker dat bepaalde websites in Opera niet meer goed werken.

[roeleboel]

Relief2009 schreef op woensdag 01 augustus 2012 @ 02:57:
Ik vind het gezeik op MS wel heel makkelijk. Ik ga me toch afvragen of Opera iets niet fout doet. Ik hoor al vaker dat bepaalde websites in Opera niet meer goed werken.

Ik vind het gezeik op MSOpera wel heel makkelijk. Ik ga me toch afvragen of OperaMS iets niet fout doet. Ik hoor al vaker dat bepaalde websites in OperaIE niet meer goed werken.

ftfy

We weten allemaal wat voor reputatie IE (nog steeds) heeft...

[.oisyn]

Slechte fix. Je verwart MS met IE hier en daar. Het gaat om de browser Opera en de maker MS. IE is totaal irrelevant in dit verhaal, en in Chrome en Firefox werkt het ook.

[roeleboel]

Opera is zowel de naam van de browser als die van het bedrijf dat de browser maakt.
Als de browser iets slechts zou doen is het het bedrijf erachter dat bijgevolg een fout gemaakt heeft bij het schrijven van de browser.
Ergo, referentie naar MS is wel degelijk relevant.

Bijkomend: ge gaat me echt niet beweren dat je nooit gehoord hebt van developpers die IE naar de verdoemenis wensen omdat ze specifiek voor die browser godweetwat allemaal moeten doen.

En IE is irrelevant, maar chrome & firefox niet?

[ Voor 5% gewijzigd door roeleboel op 01-08-2012 12:19 ]

[.oisyn]

.edit: nvm, ik had een hele andere discussie voor ogen toen ik reageerde

[ Voor 80% gewijzigd door .oisyn op 01-08-2012 12:28 ]

[Dragor]

En mijn moeder zich maar afvragen waarom het niet werkt...

[jessy100]

Styxxy schreef op dinsdag 31 juli 2012 @ 18:18:
Deze verdient ook wel een plaatsje in dit topic:

[afbeelding]
(ja, dat is een alert)

En het grappige is dat de website dus perfect werkt...

hier heb ik zo'n hekel aan. webdevelopers (vooral onder de 20 jaar valt mij op) die lopen te klagen dat IE en dergelijke kut zijn en dat ze daarom dan ook maar geen moeite doen om het op te lossen maar gewoon ff een berichtje er tegenaan gooien dat IE ruk is. Het is je taak om het op te lossen.. maar nee het is de schuld van IE. zo zie je ook snel het verschil tussen de goede en de mindere.

[Onbekend]

jessy100 schreef op woensdag 01 augustus 2012 @ 13:35:
[...]


hier heb ik zo'n hekel aan. webdevelopers (vooral onder de 20 jaar valt mij op) die lopen te klagen dat IE en dergelijke kut zijn en dat ze daarom dan ook maar geen moeite doen om het op te lossen maar gewoon ff een berichtje er tegenaan gooien dat IE ruk is. Het is je taak om het op te lossen.. maar nee het is de schuld van IE. zo zie je ook snel het verschil tussen de goede en de mindere.

Als je accepteert dat de IE-gebruikers niets op jouw site te zoeken hebben, maakt dat niets uit.
De meeste andere mensen willen graag zoveel mogelijk bezoekers, en zullen er ook voor zorgen dat de site onder IE8 ook nog werkt.

[IStealYourGun]

Styxxy schreef op dinsdag 31 juli 2012 @ 18:18:
Deze verdient ook wel een plaatsje in dit topic:

[afbeelding]
(ja, dat is een alert)

En het grappige is dat de website dus perfect werkt...

Belfius bank! Hen daar ooit over gemaild en antwoord gekregen dat ze niet alle browser kunnen ondersteunen.
Nuja, er is wel wat meer fout met die bank.

[Alex)]

IStealYourGun schreef op woensdag 01 augustus 2012 @ 13:40:
[...]

Nuja, er is wel wat meer fout met die bank.

De nieuwe naam van Dexia.

[azerty]

Iedereen blijft toch gewoon Dexia zeggen, met bijbehorende negatieve associaties

[Styxxy]

jessy100 schreef op woensdag 01 augustus 2012 @ 13:35:
[...]
hier heb ik zo'n hekel aan. webdevelopers (vooral onder de 20 jaar valt mij op) die lopen te klagen dat IE en dergelijke kut zijn en dat ze daarom dan ook maar geen moeite doen om het op te lossen maar gewoon ff een berichtje er tegenaan gooien dat IE ruk is. Het is je taak om het op te lossen.. maar nee het is de schuld van IE. zo zie je ook snel het verschil tussen de goede en de mindere.

Is dat een rechtstreekse opmerking op mijn bericht, of...? Overigens ben ik het met jou eens. Zorg ervoor dat websites in alle browsers werken (en het gezeik op IE: de laatste IE is best wel nog ok.)

IStealYourGun schreef op woensdag 01 augustus 2012 @ 13:40:
[...]
Belfius bank! Hen daar ooit over gemaild en antwoord gekregen dat ze niet alle browser kunnen ondersteunen.
Nuja, er is wel wat meer fout met die bank.

Ach, ik erger me al langer aan de ICT services van Belfius (Dexia).

[azerty]

Daar gaan we weer -_-

[Onbekend]

"Big smile".
Met die tweede zin verklappen ze helaas meer dan dat ze willen.....

Snel even mijn wachtwoord wijzigen.....

[ Voor 8% gewijzigd door Onbekend op 01-08-2012 20:07 ]

[Xanion]

Even een stuk code posten die ik tegenkwam in een webapplicatie bij het bedrijf waar ik voor werk. Degene die raad welke scherm getoond gaat worden heeft gewonnen.

JavaScript:

$("#controlsHolder #menubutton").click(function(){
   Webapp.screenHolder.showScreenById("mainscreen");
if(Webapp.videoControlHolder.visible){
   Webapp.screenHolder.showScreenById("mainscreen");
}
else{
   Webapp.screenHolder.showScreenById("mainscreen");
}
});

[Creepy]

optionsscreen? En 2 keer ook nog...

[ Voor 38% gewijzigd door Creepy op 01-08-2012 21:34 ]

[Firesphere]

wsitedesign schreef op woensdag 01 augustus 2012 @ 19:55:
[afbeelding]

Daar gaan we weer -_-

Oftewel.... we weten de eerste 16 tekens van je wachtwoord sowieso?
Zucht, echt, MS? Die zo'n fout maakt?

[ValHallASW]

Firesphere schreef op woensdag 01 augustus 2012 @ 22:49:
Oftewel.... we weten de eerste 16 tekens van je wachtwoord sowieso?

Dat, of 'we hebben altijd alleen maar de eerste 16 tekens opgeslagen'.

[Voutloos]

Raar, als het gaat om reeds opgeslagen wachtwoorden hadden ze het in beide gevallen (geen hashes danwel enkel eerste 16 chars) gewoon kunnen migreren: hash op nieuwe manier maken resp. volgens oude manier checken en bijwerken bij de eerstvolgende inlog.

Er zou bijna een boete moeten zijn voor sites die dit soort restricties opleggen.

[ Voor 12% gewijzigd door Voutloos op 01-08-2012 23:22 ]

[Onbekend]

Nu ik er even over denk, waarom zou de gebruiker niet meer dan 16 karakters mogen intypen? Als een gebruiker een wachtwoord van 20 tekens intypt, en aan de serverkant worden alleen de eerste 16 karakters gebruikt werkt dat toch ook prima? De gebruiker ziet het toch niet.

Maar het blijft natuurlijk slecht.

[Caelorum]

Het hele max lengte verhaal is slecht, maar de melding kan ik alleen maar toe juichen. Hoe vaak er wel al niet mensen zijn geweest met de vraag "Waarom kan ik niet inloggen met mijn live account op mijn WP7 toestel?" alleen maar om er achter te komen dat ze dus meer dan 16 tekens proberen in te rammen. (Ja, dat gaat echt fout daar).

[Olaf van der Spek]

Caelorum schreef op donderdag 02 augustus 2012 @ 00:16:
Het hele max lengte verhaal is slecht, maar de melding kan ik alleen maar toe juichen.

Want?
Als de max length 16 is, negeer je toch alles erna?

[.oisyn]

Toch zou ik het als gebruiker wel willen weten dat maar maximaal 16 tekens van mijn wachtwoord daadwerkelijk gebruikt worden.

[Onbekend]

Waarom zou de begrenzing op 16 zijn gesteld, en niet op bijvoorbeeld 256?
Zoveel extra bytes aan data is dat ook weer niet.

[Matis]

Onbekend schreef op donderdag 02 augustus 2012 @ 08:46:
Waarom zou de begrenzing op 16 zijn gesteld, en niet op bijvoorbeeld 256?
Zoveel extra bytes aan data is dat ook weer niet.

Als je het plaintext opslaat (ik hoop van niet, maar who knows), dan verschilt dat per account met 240 bytes, vermenigvuldig dat met 1 miljard gebruikers / adressen en je database vermeerderd alleen al met 223GB per DBFS.
Nu heeft Hotmail niet 1 maar duizenden (??) servers, die dan allemaal 223GB meer nodig hebben, tel daar de iteratieve backups bij op en dan snap je waarom je niet "zomaar" naar 256 karakters gaat.
Als ze het wachtwoord hashen, dan is het een ander verhaal.
Maar als je die 256 karakters wilt gebruiken, dan weet ik niet of de kans op collisions groter wordt naarmate je meer karakters toestaat.

[Tharulerz]

Duizenden servers, die allemaal een volledige database hebben draaien? Nou nou, zo hard moet je microsoft ook niet overschatten

[cpf_]

Matis schreef op donderdag 02 augustus 2012 @ 09:05:
[...]

Als je het plaintext opslaat (ik hoop van niet, maar who knows), dan verschilt dat per account met 240 bytes, vermenigvuldig dat met 1 miljard gebruikers / adressen en je database vermeerderd alleen al met 223GB per DBFS.
Nu heeft Hotmail niet 1 maar duizenden (??) servers, die dan allemaal 223GB meer nodig hebben, tel daar de iteratieve backups bij op en dan snap je waarom je niet "zomaar" naar 256 karakters gaat.
Als ze het wachtwoord hashen, dan is het een ander verhaal.
Maar als je die 256 karakters wilt gebruiken, dan weet ik niet of de kans op collisions groter wordt naarmate je meer karakters toestaat.

De limiet op 256 karakters wilt niet zeggen dat iedereen plots die 256 karakters gaat gebruiken lijkt me zo.
Also: Hashes, they solve things.

Over password lengte: Dit verteld mij telkens onrechtstreeks dat ze een slechte backend opslagmethode hebben. Ik kan namelijk in geen enkele rationele veilige situatie bedenken waarom je zelfs maar op het gedacht zou komen om een maximale limiet op te leggen. Waarom?

Bon, er is wel eens meer wat mis met MS denk ik dan, maar ik had nou toch verwacht dat ze hun les hadden geleerd. Hoop voor niets? (Of stel ik het te zwart?)

[Enfer]

Matis schreef op donderdag 02 augustus 2012 @ 09:05:
[...]

Als je het plaintext opslaat (ik hoop van niet, maar who knows), dan verschilt dat per account met 240 bytes, vermenigvuldig dat met 1 miljard gebruikers / adressen en je database vermeerderd alleen al met 223GB per DBFS.
Nu heeft Hotmail niet 1 maar duizenden (??) servers, die dan allemaal 223GB meer nodig hebben, tel daar de iteratieve backups bij op en dan snap je waarom je niet "zomaar" naar 256 karakters gaat.
Als ze het wachtwoord hashen, dan is het een ander verhaal.
Maar als je die 256 karakters wilt gebruiken, dan weet ik niet of de kans op collisions groter wordt naarmate je meer karakters toestaat.

Ik mag er vanuit gaan dat ze inderdaad het wachtwoord hashen, maar die melding erbij geeft al aan dat er grote kans is dat dat niet gebeurt..

[ Voor 9% gewijzigd door Enfer op 02-08-2012 09:49 ]

[Caelorum]

Olaf van der Spek schreef op donderdag 02 augustus 2012 @ 00:33:
[...] Want? [...]

Precies om wat ik er vlak achteraan heb geschreven. WP7 kan (of kon iig) overweg met langere wachtwoorden en gaf keihard een foutmelding als je dat dan probeerde omdat de webservice dat niet kon. Nu is het iig duidelijk voor alle WP7 gebruikers.
Wil niet zeggen dat ze dat limiet zowiezo niet zouden moeten hebben, maar ik vermoed dat ze teveel applicaties zouden moeten veranderen als ze dit nu wel zouden toestaan, Anders krijg je namelijk veel meer situaties zoals bij WP7 al het geval was (en is denk ik nog).

[Onbekend]

Matis schreef op donderdag 02 augustus 2012 @ 09:05:
[...]

Als je het plaintext opslaat (ik hoop van niet, maar who knows), dan verschilt dat per account met 240 bytes, vermenigvuldig dat met 1 miljard gebruikers / adressen en je database vermeerderd alleen al met 223GB per DBFS.
Nu heeft Hotmail niet 1 maar duizenden (??) servers, die dan allemaal 223GB meer nodig hebben, tel daar de iteratieve backups bij op en dan snap je waarom je niet "zomaar" naar 256 karakters gaat.
Als ze het wachtwoord hashen, dan is het een ander verhaal.
Maar als je die 256 karakters wilt gebruiken, dan weet ik niet of de kans op collisions groter wordt naarmate je meer karakters toestaat.

Als elke gebruiker een e-mailtje ontvangt ben je die hoeveelheid aan opslag ook kwijt, dus ik heb niet het idee dat een beperking van de opslagcapaciteit een reden was om het wachtwoord maar 16 tekens lang te maken.

[.oisyn]

cpf_ schreef op donderdag 02 augustus 2012 @ 09:32:
Over password lengte: Dit verteld mij telkens onrechtstreeks dat ze een slechte backend opslagmethode hebben. Ik kan namelijk in geen enkele rationele veilige situatie bedenken waarom je zelfs maar op het gedacht zou komen om een maximale limiet op te leggen. Waarom?

Simpel: denial of service attacks door de server hele lange wachtwoorden te laten hashen.

[Orion84]

Dragor schreef op woensdag 01 augustus 2012 @ 13:31:
En mijn moeder zich maar afvragen waarom het niet werkt...

[afbeelding]

Om ontopic te blijven: volgens een reactie op het forum van security.nl zit de password validator in de clientside JS code

Gelukkig is het /resources/js/validatie.js die het wachtwoord controleert

rege = /^((?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[._!@#$%]).{8,50})$/i;


Even wat javascript aanpassen en een 1 char wachtwoord werkt ook. Wel makkelijk, want ik vergeet mijn wachtwoorden altijd.

http://www.security.nl/ar...liging_bij_Simpel.nl.html (even naar onder scrollen, ze hebben daar geen deeplinks naar reacties)

Ik kan alleen maar hopen dat er ook nog een server side validatie is en dat degene die die bevinding postte alleen naar de code gekeken heeft en het niet heeft uitgeprobeerd.

[roy-t]

Als dit MS is, is dit waarschijnlijk ook ASP.NET, waarin je bijna by default client en server validatie krijgt, zou me daar dus niet al te druk over maken

Oeps dacht dat je het over Outlook.com had

[ Voor 14% gewijzigd door roy-t op 02-08-2012 13:05 ]

[.oisyn]

Orion84 schreef op donderdag 02 augustus 2012 @ 13:01:
http://www.security.nl/ar...liging_bij_Simpel.nl.html (even naar onder scrollen, ze hebben daar geen deeplinks naar reacties)

Amateur

[Orion84]

.oisyn schreef op donderdag 02 augustus 2012 @ 13:15:
[...]

Amateur

Heb je de anchor code uit de HTML source gevist, of zie ik echt ergens een element in de userinterface over het hoofd waar ik zo'n linkje uit op kan vissen?

[.oisyn]

HTML:

<div class="comment discussie" id="comment-291583">

Dat dus

[Patriot]

Daarvoor heb je even de realisatie nodig dat je een id ook kunt gebruiken als anchor. Daar kwam ik relatief recent ook achter, na ruim 10 jaar ervaring met HTML

[cpf_]

.oisyn schreef op donderdag 02 augustus 2012 @ 12:30:
[...]

Simpel: denial of service attacks door de server hele lange wachtwoorden te laten hashen.

In dat geval lijkt het me evidenter om een server memory te gaan vorstampen...
Performance van een sha512 is best hoog, het zal langer duren om je wachtwoord dan door te sturen dan dat de server dit zal hashen.
Nonargument tbh.

* cpf_ gaat dit thuis even proberen testen wel, meten is weten!

[BtM909]

Orion84 schreef op donderdag 02 augustus 2012 @ 13:19:
[...]

Heb je de anchor code uit de HTML source gevist, of zie ik echt ergens een element in de userinterface over het hoofd waar ik zo'n linkje uit op kan vissen?

Nee, geen UI ervoor

Gewoon inspect element doen en de dichstbijzijnde ID als anchor opgeven

[Verwijderd]

wsitedesign schreef op woensdag 01 augustus 2012 @ 19:55:
[afbeelding]

Daar gaan we weer -_-

Begrijp ik nu dat ze dus geen hashes hebben gebruikt? Of zouden ze de hashes afkappen en die checken?

[Verwijderd]

Verwijderd schreef op donderdag 02 augustus 2012 @ 23:56:
[...]

Begrijp ik nu dat ze dus geen hashes hebben gebruikt? Of zouden ze de hashes afkappen en die checken?

hashes afkappen?!, da kan nie he

[cpf_]

Verwijderd schreef op vrijdag 03 augustus 2012 @ 01:27:
[...]

hashes afkappen?!, da kan nie he

Tuurlijk wel. Erger zelfs, ik heb dit (ongewild) in php/mysql al zien gebeuren...

[Paul]

Dat is te letterlijk geïnterpreteerd denk ik Als je een hash afkapt dan komt deze niet meer overeen met de hash van het originele wachtwoord.

Als je de eerste 16 chars van een wachtwoord hasht komt er als het goed is iets compleet anders uit dan wanneer je het hele wachtwoord (mits dat langer is dan 16 tekens) hasht.

Oftewel: Ze slaan je wachtwoord ofwel plain-text ofwel reversibly encrypted op.

[MBV]

Of ze hadden een tussenlaag die alles langer dan X tekens afkapte voor het door MD5/SHA werd gehaald, en die tussenlaag is nu weg/verbeterd.

[Onbekend]

MBV schreef op vrijdag 03 augustus 2012 @ 10:00:
Of ze hadden een tussenlaag die alles langer dan X tekens afkapte voor het door MD5/SHA werd gehaald, en die tussenlaag is nu weg/verbeterd.

Dan hadden zie 16-tekens limiet aan de user-kant ook kunnen verwijderen en wanneer het form aan de server wordt aangeboden, bij de gebruikelijke controles het wachtwoord meteen op 16 tekens afkappen.

[MBV]

En de nieuwe wachtwoorden dan, die wel 20 tekens lang mogen zijn? Maakt het niet minder slecht natuurlijk, dat ze jaren hebben toegestaan dat je een wachtwoord van X karakters hebt mogen invoeren terwijl maar 16 tekens werden gecheckt

[.oisyn]

Onbekend schreef op vrijdag 03 augustus 2012 @ 10:03:
[...]

Dan hadden zie 16-tekens limiet aan de user-kant ook kunnen verwijderen en wanneer het form aan de server wordt aangeboden, bij de gebruikelijke controles het wachtwoord meteen op 16 tekens afkappen.

.oisyn schreef op donderdag 02 augustus 2012 @ 01:57:
Toch zou ik het als gebruiker wel willen weten dat maar maximaal 16 tekens van mijn wachtwoord daadwerkelijk gebruikt worden.

[Onbekend]

@oisyn:
Dat was geen reactie op jouw reactie, maar dat had je waarschijnlijk al gezien.

Ik had ook graag gezien dat meer websites duidelijk aangeven van wat ze met het wachtwoord doen voordat deze in de database wordt opgeslagen.
Echter, voor de meeste gebruikers maakt het totaal niet uit hoe veilig hun wachtwoord is. En of dit wachtwoord over een beveiligde verbinding wordt verzonden of niet, ze willen gewoon kunnen inloggen en de manier waarop maakt is totaal niet interessant!

[.oisyn]

Onbekend schreef op vrijdag 03 augustus 2012 @ 11:13:
@oisyn:
Dat was geen reactie op jouw reactie

Dat snap ik ook wel, wat ik bedoel is dat mijn eerdere opmerking ook op jouw post van toepassing is. Ik stel slechts dat ik het fijn vind om te weten dat mijn wachtwoord afgekapt wordt, in plaats van gewoon maar stilletjes het wachtwoord af te kappen zoals jij voorstelt. Wellicht dat MS er ook zo over denkt.

cpf_ schreef op donderdag 02 augustus 2012 @ 14:59:
[...]

In dat geval lijkt het me evidenter om een server memory te gaan vorstampen...
Performance van een sha512 is best hoog, het zal langer duren om je wachtwoord dan door te sturen dan dat de server dit zal hashen.
Nonargument tbh.

Het is alleen maar een nonargument omdat jij er vanuit gaat dat ze hun zaakjes niet op orde hebben en een snel hash algoritme gebruiken. Goede password hashing algoritmes zijn er juist op gebouwd dat het hashen een time consuming proces is om het een attacker behoorlijk moeilijk te maken bemachtigde hashes te brute-forcen. En dus gebruik je niet SHA-512, maar iets als PBKDF2 of bcrypt.

[ Voor 56% gewijzigd door .oisyn op 03-08-2012 11:47 ]

[cpf_]

.oisyn schreef op vrijdag 03 augustus 2012 @ 11:39:
[...]

Dat snap ik ook wel, wat ik bedoel is dat mijn eerdere opmerking ook op jouw post van toepassing is. Ik stel slechts dat ik het fijn vind om te weten dat mijn wachtwoord afgekapt wordt, in plaats van gewoon maar stilletjes het wachtwoord af te kappen zoals jij voorstelt.


[...]

Het is alleen maar een nonargument omdat jij er vanuit gaat dat ze hun zaakjes niet op orde hebben en een snel hash algoritme gebruiken. Goede password hashing algoritmes zijn er juist op gebouwd dat het hashen een time consuming proces is om het een attacker behoorlijk moeilijk te maken bemachtigde hashes te brute-forcen. En dus gebruik je niet SHA-512, maar iets als PBKDF2 of bcrypt.

Om eerlijk te zijn zie ik het probleem niet van sha-512 tov , ik had namelijk rekening gehouden met hash iteratie en salting, peppering, opzich natuurlijk geen wonderlijke zaken. Ik heb eerder de indruk dat jij denkt dat ik mijn zaken niet op orde heb?
Een check op (korte) lengte is imho niet nodig, en al zeker niet op 16 karakters, ik denk dat het gevaar maar komt in de buurt van de 1000 karakters. Moet ik de eerste nog zien die zo'n groot wachtwoord in z'n keepass staan heeft... (Also: rond de 100 karakters zou ik het acceptabel vinden om een weigering te doen, 16, nogmaals, niet)
Verder ga ik er denk ik ook niet tezeer op ingaan, het begint behoorlijk OT te gaan, en naar mijn gevoel wordt het een discussie van hardware, en niet software: Smijt er voldoende hw tegenaan en je denial of service kan mooi de deur worden gewezen.

[.oisyn]

Het ging niet om 16, het ging om de stelling "waarom zou je er überhaupt een maximale limiet op zetten". Ik vind 16 ook wat kort en zou zelf eerder denken in de orde van grootte van 100 of 1000, maar daar ging het niet om.

Overigens:

ik had namelijk rekening gehouden met hash iteratie

Als je daar rekening mee hebt gehouden, waarom kom je dan met de opmerking dat de performance van SHA-512 best hoog is

[ Voor 70% gewijzigd door .oisyn op 03-08-2012 12:05 ]

[cpf_]

.oisyn schreef op vrijdag 03 augustus 2012 @ 11:57:
Het ging niet om 16, het ging om de stelling "waarom zou je er überhaupt een maximale limiet op zetten". Ik vind 16 ook wat kort en zou zelf eerder denken in de orde van grootte van 100 of 1000, maar daar ging het niet om.

Overigens:

[...]

Als je daar rekening mee hebt gehouden, waarom kom je dan met de opmerking dat de performance van SHA-512 best hoog is

Nou, we zijn iig akkoord dat 16 niet de bedoeling is.
Ivm de sha-512: Ik snap je punt niet 100%, als een iteratie van 1000x vlot verloopt terwijl het wel een sterke bescherming bied, is dat dan niet een teken van performantie?

[.oisyn]

Nee, de performance van een enkele iteratie van het algoritme is niet relevant. Het idee van de iteraties is louter dat de hash dusdanig veel tijd in beslag neemt dat brute-forcen oninteressant is. Verder biedt het geen enkele vorm van extra bescherming. Uiteindelijk wil je uitkomen op ongeveer X tijd per hash, en daar stem je je aantal iteraties op af. Als je een snel algoritme kiest (zoals MD5) dan gebruik je een hoog aantal iteraties. Als je een langzaam algoritme kiest dan gebruik je minder iteraties. Het aantal iteraties groeit dus typisch ook met hardwarematige ontwikkelingen.

[cpf_]

.oisyn schreef op vrijdag 03 augustus 2012 @ 12:30:
Nee, de performance van een enkele iteratie van het algoritme is niet relevant. Het idee van de iteraties is louter dat de hash dusdanig veel tijd in beslag neemt dat brute-forcen oninteressant is.

Noted.

.oisyn schreef op vrijdag 03 augustus 2012 @ 12:30:
Verder biedt het geen enkele vorm van extra bescherming. Uiteindelijk wil je uitkomen op ongeveer X tijd per hash, en daar stem je je aantal iteraties op af. Als je een snel algoritme kiest (zoals MD5) dan gebruik je een hoog aantal iteraties. Als je een langzaam algoritme kiest dan gebruik je minder iteraties. Het aantal iteraties groeit dus typisch ook met hardwarematige ontwikkelingen.

De extra bescherming ligt hem net in de extra tijd die het in beslag zou nemen om iedere iteratie uit de doeken te gaan doen. Dat is dan ook wat ik bedoelde.
Hash iteratie op zich heeft cryptografisch gezien net het omgekeerde effect, hierover heb ik met Bart Preneel even gesproken (For the record: Hash iteratie is _wel_ goed! Met als doel om de aanvaller z'n tijd te stelen), hij sprak van een verkleining van het sleuteldomein. Salt en peppers zijn dan weer extra tijdeters.

[.oisyn]

Je moet dan ook niet zomaar hashes gaan hashen, maar je baseren op bewezen algoritmes (zoals PDKDF2), die het sleuteldomein juist niet verkleinen.

[.oisyn]

Eentje van mezelf. We zaten even met de handen in het haar, totdat het ineens duidelijk werd. Het werkte namelijk wel op PC en Xbox 360, maar niet goed op de PS3.

De code, zwaar overgesimplificeerd:

C++:

#include <iostream>

int value;

int foo()
{
    value++;
    return 1;
}

int main()
{
    value = 0;
    value += foo();
    std::cout << value << std::endl;
}

Wat output dit?

[GekkePrutser]

.oisyn schreef op dinsdag 07 augustus 2012 @ 13:26:

Wat output dit?

2

Mis je niet nog een .h achter iostream trouwens?

[ Voor 15% gewijzigd door GekkePrutser op 07-08-2012 13:34 ]

[frG]

GekkePrutser schreef op dinsdag 07 augustus 2012 @ 13:33:
[...]


2

Mis je niet nog een .h achter iostream trouwens?

Snel aanpassen he

[.oisyn]

GekkePrutser schreef op dinsdag 07 augustus 2012 @ 13:33:
[...]


2

*BEEP*

Het antwoord is: ongedefinieerd. MSVC++ zegt 2. GCC (met optimalisaties) zegt 1.

Mis je niet nog een .h achter iostream trouwens?

Euh, nee.

[GekkePrutser]

frG schreef op dinsdag 07 augustus 2012 @ 13:34:
[...]
Snel aanpassen he

Ja klopt Ik had eerst 1 staan

Nou heb ik al jaren geen C++ meer gedaan, dus het is me niet helemaal duidelijk waarom dit fout gaat afhankelijk van de compiler.

[RayNbow]

.oisyn schreef op dinsdag 07 augustus 2012 @ 13:36:
Het antwoord is: ongedefinieerd.

Nu is mijn C++ niet zo goed, maar komt dat doordat value += foo(); gelijk is aan value = value + foo(); en er dus niet gespecificeerd is welke van de twee operanden als eerste geëvalueerd wordt?

[ValHallASW]

.oisyn schreef op dinsdag 07 augustus 2012 @ 13:36:
Het antwoord is: ongedefinieerd. MSVC++ zegt 2. GCC (met optimalisaties) zegt 1.

Dat twee compilers iets anders doen betekent nog niet dat het ongedefinieerd is ;-)

Overigens moest ik even puzzelen op wáárom het ongedefinieerd is, maar het is zo opgeschreven vrij evident:

C++:

int foo() 
{ 
    value++; 
    return 1; 
} 

value = value + foo();

@RayNbow:

quote: http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.5.html

expression1 += expression2
The value of expression1 plus expression2 is stored in expression1.

[ Voor 16% gewijzigd door ValHallASW op 07-08-2012 13:49 ]

[ReTechNL]

ValHallASW schreef op dinsdag 07 augustus 2012 @ 13:48:
[...]

Dat twee compilers iets anders doen betekent nog niet dat het ongedefinieerd is ;-)

Overigens moest ik even puzzelen op wáárom het ongedefinieerd is, maar het is zo opgeschreven vrij evident:

C++:

int foo() 
{ 
    value++; 
    return 1; 
} 

value = value + foo();

@RayNbow:

[...]

De compiler ziet value++ als ongedefineerd omdat deze nog niet bekend is in de functie. anders had het als volgt moeten zijn.

C++:

int foo(int value) 
{ 
    value++; 
    return 1; 
} 

value = value + foo(value);

maar dan zou hij alsnog niks moeten doen met de value++ omdat die niet ge returnt wordt.
Mijn C++ is een beetje roestig... So if i am wrong don't shoot me.

[ValHallASW]

ReTechNL schreef op dinsdag 07 augustus 2012 @ 13:58:
De compiler ziet value++ als ongedefineerd omdat deze nog niet bekend is in de functie. anders had het als volgt moeten zijn.

value is een global (die ik inderdaad niet ook in mijn codevoorbeeld op heb genomen, maar dat is omdat ik aan oisyn's voorbeeld refereer).

[ Voor 18% gewijzigd door ValHallASW op 07-08-2012 14:06 ]

[Caelorum]

ValHallASW schreef op dinsdag 07 augustus 2012 @ 13:48:
[...] Overigens moest ik even puzzelen op wáárom het ongedefinieerd is, maar het is zo opgeschreven vrij evident:

C++:

int foo() 
{ 
    value++; 
    return 1; 
} 

value = value + foo();

Zo evident vind ik het niet. Nu is mijn ervaring met c++ nog maar enkele dagen oud, maar is het niet zo dat eerst foo() wordt geevalueerd, dan value, dan + en dan de assignment?

[ Voor 8% gewijzigd door Caelorum op 07-08-2012 14:09 ]

[.oisyn]

ValHallASW schreef op dinsdag 07 augustus 2012 @ 13:48:
[...]

Dat twee compilers iets anders doen betekent nog niet dat het ongedefinieerd is ;-)

Het feit dat ik twee dingen zeg in mijn reactie betekent nog niet dat ze aan elkaar gelinkt zijn

De standaard zegt dat het ongedefinieerd is.

[Ram0n]

Nee, daar kan je dus juist niet van uitgaan. Dit is in Leiden ook een standaard tentamenvraag die er elk jaar weer in zit en toch (ondanks de oefententamens) nog vaak fout gaat.

[.oisyn]

RayNbow schreef op dinsdag 07 augustus 2012 @ 13:45:
[...]

Nu is mijn C++ niet zo goed, maar komt dat doordat value += foo(); gelijk is aan value = value + foo();

Nee

en er dus niet gespecificeerd is welke van de twee operanden als eerste geëvalueerd wordt?

Dat dan weer wel

[roy-t]

Het verbaast me eigenlijk dat GCC er 1 van maakt. Je zou denken dat, omdat foo() uitgerekend moet worden om de rechterkant van de += uit te rekenen, er uiteindelijk 1 += 1 staat. Hoe zou de doorloop in de geoptimaliseerde GCC versie zijn? Zou deze de waarde van value naar een register kopiëren en dan de hele rechterkant uitrekenen deze bij de register waarde optellen en daarna deze register waarden aan M(value) toewijzen?

[alienfruit]

En hoe heb je dit nu opgelost ?

[Jegorex]

alienfruit schreef op dinsdag 07 augustus 2012 @ 14:22:
En hoe heb je dit nu opgelost ?

code:

value = foo() + value;

?

[RayNbow]

.oisyn schreef op dinsdag 07 augustus 2012 @ 14:13:
[...]

Nee

Hmm...

quote: http://msdn.microsoft.com...6z5yhhs%28v=vs.80%29.aspx

Using this operator is almost the same as specifying result = result + expression, except that result is only evaluated once.

Dus het enige verschil is dat result eenmalig geëvalueerd wordt?

[.oisyn]

roy-t schreef op dinsdag 07 augustus 2012 @ 14:17:
Het verbaast me eigenlijk dat GCC er 1 van maakt. Je zou denken dat, omdat foo() uitgerekend moet worden om de rechterkant van de += uit te rekenen, er uiteindelijk 1 += 1 staat.

Het kwam hierop neer in assembly:

C++:

register int tmp1 = value;
register int tmp2 = foo();
value = tmp1 + tmp2;

Let wel, het was PowerPC - de x86 heeft hier minder snel last van omdat je gewoon meteen een register bij een waarde in het geheugen op kan tellen.

Jegorex schreef op dinsdag 07 augustus 2012 @ 14:38:
[...]

code:

value = foo() + value;

?

Dat geeft hetzelfde probleem. Gewoon:

C++:

int result = foo();
value += result;

[ Voor 18% gewijzigd door .oisyn op 07-08-2012 14:44 ]

[Dido]

Ik zou hier wel wat willen posten, maar mijn code is nog niet af

[Otherside1982]

Dido schreef op woensdag 08 augustus 2012 @ 07:45:
Ik zou hier wel wat willen posten, maar mijn code is nog niet af

Dat telt ook als slecht programmeervoorbeeld, dat valt onder "Premature Optimization". Code willen posten voor hij af is.

---

Zelf ben ik op dit moment bezig om iets te implementeren dat analoog is aan iets dat ik 4 jaar geleden ook al gedaan heb. Ik ben dus ook die code van 4 jaar geleden aan het bekijken om dingen over te nemen, en het valt me eigenlijk heel goed mee om zo'n oude code van mezelf terug te zien.

[Alex)]

Toch leuk dat een lijst waarin alleen maar nummers voor kunnen komen van het type List<string> is

[PiepPiep]

.oisyn schreef op dinsdag 07 augustus 2012 @ 14:42:
[...]
Het kwam hierop neer in assembly:

C++:

register int tmp1 = value;
register int tmp2 = foo();
value = tmp1 + tmp2;

Let wel, het was PowerPC - de x86 heeft hier minder snel last van omdat je gewoon meteen een register bij een waarde in het geheugen op kan tellen.

Ah, vandaar, ik snapte al niet dat hij die instructie niet gebruikte. Maar dan heb je dus best kans dat gcc voor x86 wel met 2 als antwoord komt.

[.oisyn]

Zou kunnen ja. MSVC++ doet op beide platforms iig hetzelfde.

[Wijnbo]

Alex) schreef op woensdag 08 augustus 2012 @ 09:48:
Toch leuk dat een lijst waarin alleen maar nummers voor kunnen komen van het type List<string> is

Dat is toch logisch?

C#:

List<String> _numbers = new List<string>():
_numbers.Add("One")
_numbers.Add("Two")
_numbers.Add("Three")
_numbers.Add("Twenty")

[DEiE]

Alex) schreef op woensdag 08 augustus 2012 @ 09:48:
Toch leuk dat een lijst waarin alleen maar nummers voor kunnen komen van het type List<string> is

Telefoonnummers bijvoorbeeld wil je ook echt niet als integers opslaan, ook al zijn het enkel nummers

Nog een mooi verhaaltje daarover: Confessions: The Phone Number

[ Voor 18% gewijzigd door DEiE op 09-08-2012 14:58 ]

[Ozzie]

DEiE schreef op donderdag 09 augustus 2012 @ 14:56:
[...]

Telefoonnummers bijvoorbeeld wil je ook echt niet als integers opslaan, ook al zijn het enkel nummers

Nog een mooi verhaaltje daarover: Confessions: The Phone Number

Hehe, dit heb ik op school mensen ook weleens fout zien doen. Maar dan bij Nederlandse telefoonnummers opgeslagen als int in een database en dan hardcoded een 0 ervoor zetten omdat die niet werden opgeslagen

[Orion84]

Ozzie schreef op donderdag 09 augustus 2012 @ 15:34:
[...]


Hehe, dit heb ik op school mensen ook weleens fout zien doen. Maar dan bij Nederlandse telefoonnummers opgeslagen als int in een database en dan hardcoded een 0 ervoor zetten omdat die niet werden opgeslagen

Ook altijd leuk met bulk data invoer waarbij eerst in excel nog wat bewerkingen op de data worden gedaan. Personeelsnummers die hun leading zero's kwijtraken, of die ineens in wetenschappelijke notatie komen te staan

Met als gevolg dat het systeem waar de data wordt ingevoerd de personeelsnummers niet kan matchen met bestaande entries en ze dus als nieuwe records beschouwt.

[ Voor 12% gewijzigd door Orion84 op 09-08-2012 15:41 ]

[Alex)]

DEiE schreef op donderdag 09 augustus 2012 @ 14:56:
[...]

Telefoonnummers bijvoorbeeld wil je ook echt niet als integers opslaan, ook al zijn het enkel nummers

In dit geval ging het om identifiers, datatype ook echt Int32...

[Spockz]

Alex) schreef op donderdag 09 augustus 2012 @ 16:33:
[...]

In dit geval ging het om identifiers, datatype ook echt Int32...

We gebruiken vaak genoeg Integers om identifiers een uniek naampje te geven. Wat is daar mis mee?

[CodeCaster]

Niks, dat bedoelt hij ook. Hij heeft objecten met een Int32 identifier, en de lijst met identifiers is van het type List<string>.

[Haan]

Ik heb weer eens een echt pareltje gevonden

C#:

//Haal de eerste 4 nummers uit het textveld
int i = ConvertString(PostalCode.Substring(0, 4));

private bool isInt(string strNr)
{
    if (strNr == "0" || strNr == "1" || strNr == "2" || strNr == "3" || strNr == "4" || strNr == "5" ||
        strNr == "6" || strNr == "7" || strNr == "8" || strNr == "9")
    {
        return true;
    }
    return false;
}

private int ConvertString(string strNumber)
{
    if (isInt(strNumber.Substring(0, 1)) && isInt(strNumber.Substring(1, 1)) && isInt(strNumber.Substring(2, 1)) &&
        isInt(strNumber.Substring(3, 1)))
    {
        return Convert.ToInt32(strNumber);
    }
    return 0;
}

[Firesphere]

Haan schreef op woensdag 15 augustus 2012 @ 12:05:
Ik heb weer eens een echt pareltje gevonden

C#:

//Haal de eerste 4 nummers uit het textveld
int i = ConvertString(PostalCode.Substring(0, 4));

private bool isInt(string strNr)
{
    if (strNr == "0" || strNr == "1" || strNr == "2" || strNr == "3" || strNr == "4" || strNr == "5" ||
        strNr == "6" || strNr == "7" || strNr == "8" || strNr == "9")
    {
        return true;
    }
    return false;
}

private int ConvertString(string strNumber)
{
    if (isInt(strNumber.Substring(0, 1)) && isInt(strNumber.Substring(1, 1)) && isInt(strNumber.Substring(2, 1)) &&
        isInt(strNumber.Substring(3, 1)))
    {
        return Convert.ToInt32(strNumber);
    }
    return 0;
}

Wat is daar mis mee? Je moet toch controleren of het alle 4 wel getallen zijn?

[Amras]

C#:

isInt("42")  // false.. FFFFUUUUUUUUU!! :(