Pistike BKK webshopot ír

Pistike BKK webshopot ír
2017-07-15T21:05:52+02:00
2017-07-27T08:05:41+02:00
2022-10-19T12:41:56+02:00
  • Sehol nem írtam, hogy minden olyan rossz. Vannak hibák a rendszerben, de ez nem hiba, hanem ez az eset a neokommunista rendszer alapvető működését mutatja be. Minden benne van, amit egyébként nem is titkolnak, mert szerintük így jó. A drága de kritikán aluli minőségű közbeszerzés, a sokszori szívatás után behódoló, és immár hűbéressé vált cégcsoport, a hatalmi arrogancia azokkal szemben, akik valamin javítani szeretnének, legyen barmilyen kis dologról is szó, a nyilvánvaló, ellenőrízhetö tényekben is utólagos hazugság (BKK vezérigazgatóna), ami úgysem számít, mert a propaganda médiába úgyis csak a hazug állítás, a cáfolat nem jut el.

    Aki nyitott szemmel jár, az tudja, hogy ugyanez kicsiben, nem publikusan is rengetegszer megtörténik az országban.
    Mutasd a teljes hozzászólást!
  • En spec a telekomnal dolgoztam mint alvallakozo es ennel sokkal rosszab dolgok is vannak, meg aztan az is tipikus hogy sokszor olyan kapja a munkakat aki ismeri a megfelelo embert de senki sem nezi hogy ert is-e hozza
    Mutasd a teljes hozzászólást!
  • Dolgoztam nagy cégnél, az egyik legnagyobbnál. El is mentem, mert nem tetszett az erőltetett menet. Náluk is volt gányolás rövid határidővel, de ekkora szakmai hibákat el sem tudtam volna képzelni abban a csapatban.
    Mutasd a teljes hozzászólást!
  • Ilyet csak az mond, aki nem dolgozott nagy cegnel.
    Mutasd a teljes hozzászólást!
  • Hat ugy megy ez, hogy kaptam x parszaz millio ra, levettek belole y-t...etc. A vegen Gipsz Jakabka meg megirta olcsoer.

    Magyar mentalitas. Csak most ugye visszanyalt a fagyi.
    Mutasd a teljes hozzászólást!
  • Hali!

    Ugyanakkor sokan itt láthatóan azt gondolják, hogy 10 perc lett volna javítani a jelszókezelést…

    Nem javítani, hanem eleve megfelelően készíteni. És nagyon több időbe nem került volna, ha egy profi, gyakorlott cég/programozó készíti (ebből – is – látszik, hogy nem ilyenek készítették). 

    Mutasd a teljes hozzászólást!
  • Egyebkent valoszinu, hogy ha valakiken csattan is vegul az ostor, azok a  "szegeny fejlesztok" lesznek, es az igazi felelosok, akik ezt az egeszet levezenyeltek, rabolintottak stb, megusszak buntetlenul, sot adott esetben profitalnak is belole.
    Mutasd a teljes hozzászólást!
  • Nem sugallok semmit, ezt legfeljebb te látod bele a hozzászólásaimba. Szögezzük le: nincs mentség ilyen szintű hibákra, a project bevezetését el kellett volna halasztani.

    Ugyanakkor sokan itt láthatóan azt gondolják, hogy 10 perc lett volna javítani a jelszókezelést ("miért nem hash-elték el és kész"), én meg próbáltam rávilágítani, hogy a dolog ekkor már bonyolultabbá válik, és valószínűleg ezért döntöttek a plain text jelszó mellett.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • napi 16 órát dolgozol, így van még további 5 perced a regisztrációs rész befejezésére

    van olyan helyzet, hogy teljesen lehetetlen követelményekkel stresszelnek

    Időhiánnyal küszködtek

    Egy ideje már azt sugallod, hogy érthetőek a hibák, hiszen a szegény fejlesztőknek nem volt ideje rendesen megcsinálni a rendszert. Szerintem ez nem mentség.
    Mutasd a teljes hozzászólást!
  • egy ideje napi 16 órát dolgozol, így van még további 5 perced a regisztrációs rész befejezésére. Hogy kezeled le, ha a felhasználó elfelejti a jelszavát?

    Felmondok es nem folytatom a munkat egy olyan helyen ami szakmai integritasom feladasara kenyszerit.
    Mutasd a teljes hozzászólást!
  • Kérlek, mutass rá, ki és hol állt ki a T fejlesztői mellett!
    Mutasd a teljes hozzászólást!
  • Nem tudom, mi az oka ennek a nagy kiállásnak a T fejlesztői mellett, de a plaintext jelszótárolás és -küldés akkora hiba, amit még egy belső használatra szánt demóban sem lehet megengedni, sőt megkockáztatnám, hogy már egy egyetemi beadandóban is buktatnak érte adott esetben. Én is befejlesztettem már nagyon rövid határidővel százmilliós, állami finanszírozású szoftverbe, ami szintén tele volt hülyeségekkel és hibákkal, de az első tesztkörön kiesett volna egy ilyen. Ilyet egyszerűen meg se szabad írni, annyira súlyos, hogy még PoC-nak sem megy el. (Szvsz.)

    Persze lehet azt is mondani, hogy ha nincs tesztelés, akkor nem veszik észre a hibákat. Ez logikus is lenne, de ha a fejlesztő tudja, hogy nem lesz tesztelve a kódja release előtt, főleg figyeljen oda, hogy ne kerüljenek bele olyan marhaságok, amiket egyértelműen kidobna az első junior tesztelő vagy bárki egy code review-n, aki 3 sornál többet kódolt életében. Hanyagság és inkompetencia jellemezte ezt az egész projectet, erre nem mentség az sem, ha nagyon gyorsan kellett vele elkészülniük.
    Mutasd a teljes hozzászólást!
  • Kene egy fontossagi sorrend. De gyanitom ittis fontosabb volt a gombok szine es a betutipusok.
    Mutasd a teljes hozzászólást!
  • Amellett, hogy egyetértek veled a nem helyes jelszótárolásról, gondolatkísérlet:

    egy ideje napi 16 órát dolgozol, így van még további 5 perced a regisztrációs rész befejezésére. Hogy kezeled le, ha a felhasználó elfelejti a jelszavát?
    Mutasd a teljes hozzászólást!
  • Szuper bonyolult egy bcrypt lib-et letölteni (sok nyelv-ben alapból benne van) majd include-olni a kódba és egy függvényt használni regisztrációnál és egy másik függvényt bejelentkezésnél a lib-ből. kb 10 perc implementálni az egészet és akkor belefért egy kávé+cigi. 

    A nem helyes jelszó tárolásnak minimum szabálysértésnek kellene lennie vagy az adatvédelmi nyilatkozatban ott kéne lennie ,hogy a felhasználó egyes adatai nincsenek biztonságosan kezelve.
    Mutasd a teljes hozzászólást!
  • Hali!

    De arra próbáltam rámutatni - bár nem értem, ez miért nem evidens -, hogy a helyes jelszókezelés elkészítése jóval-jóval bonyolultabb annál, mint hogy berakunk egy hash függvényt.

    Ebben igazad van, egyet is értek. Valószínűleg félreértettem akkor azt, hogy (kiemelve) az elfelejtett jelszó funkcióval közös kontextusban említetted a hash-elést.

    Komolyan nem értem, mit nem lehet ezen érteni.

    Mindent lehet érteni, csak megfelelően kell elmagyarázni. 

    Mutasd a teljes hozzászólást!
  • Igen, mikor a php programoztast tanultam, akkor irtam egy tarskereso rendszert juniorkent, vagy meg az se voltam, Nulladik project (tanulasi project), extra .hu-n, ott enis plaintextben csinaltam.

    Kb 1 hetig maradt ugy, mert utana olvastam, hogy ez igy nem jo, talan pont itt.., es valtottam md5-re. Es ekkor tenyleg iskolas voltam, szoval enis hasonlot kepzelek el.

    Es igen enis csinaltam anno hulyesegeket, kb 18-19 evesen, pl sajat CAPTCHA-t irtam, persze hasznalhatatlan volt az egesz, aztan valtottam, mert torheto volt..
    Mutasd a teljes hozzászólást!
  • Nem ismerem a hátteredet és a tapasztalataidat, de van olyan helyzet, hogy teljesen lehetetlen követelményekkel stresszelnek.

    Ilyenkor nincs jó megoldás, csak az, hogy el kell kerülni az ilyen helyzeteket.
    Mutasd a teljes hozzászólást!
  • Hat nalam semmi sem vilagos ott mi tortent:D Mintha egy masik dimenzioban lenne az egesz.
    Merthat tenyleg mennyi iylen tema van a szakmaban, hogy plaintextben SOHA SEMMIT.

    Meghogy MD5-ben SE MÁR. Ezeknek alapvetonek kene lenni.

    Meghat, hogy atirsz egy szamot es az a fizetseg... Arat atkuldeni postban:D Nem valami id/token-t, vagy akarmi mast.

    Meg, hogy HACKER, aki POST-ot atir.. Vicc az egesz:D
    Mutasd a teljes hozzászólást!
  • Bocs, de szerintem én sem értem. Ha nincs idő megírni egy biztonságos jelszó visszaállítást, akkor nem írok semmilyet.
    Egyedül azzal tudnám menteni a fejlesztőket ha kiderülne, azt hazudták nekik hogy csak egy gyors demó kell belső használatra, de legyen ám benne jelszó reset. Aztán kiment élesbe a tudtuk nélkül.
    De ez azért már elég meredek, sokkal valószínűbbnek tartom hogy egyszerűen ingyen dolgoztatott középiskolás gyakornokok fejlesztették az egészet, akik tényleg ennyit tudnak.
    Mutasd a teljes hozzászólást!
  • Kicsit write-only módban vagy: már kétszer leírtam, hogy nem világos, miért nem használtak fel meglévő kiforrott libet.

    Ez viszont azon a tényen nem változtat, hogy ha valamilyen okból ezt nem tehették (van ilyen: eltérő platform, jogi okok, megbízhatatlan külső kód stb.), akkor jóval egyszerűbb és gyorsabb a plain text és jelszóküldés.

    Szerk.: ha te ugyanannyi idő alatt megírsz és letesztelsz 0-ról egy megbízható jelszókezelést, mint elküldeni email-ben egy értéket egy adatbázisból, akkor nincs miről beszélnünk.
    Mutasd a teljes hozzászólást!
  • Pedig nem, nem bonyolultabb annal. Ha mar egyszer megirtad, akkor onnan atemeled es problema solved. Es mivel mar vagy 15 eve tuti megirtam egyszer, nem kell ujra feltalalni ujra es ujra:D

    Kikuldeskor generalsz egy random tokent, berakod tablaba, aztan usernek hagysz x idot mig ranyomhat. Ha lejart, csinalod a folyamatot ujra.
    NEM KELL semmifele jelszot kuldozgetni SEHOVA.

    De egyebkent, tuti vannak kesz mukodni peldanyok barhol mashol is. Stackoverflowra pl miert jarnak az emebrek? Pont azert, hogy az ilyen kerdesekre valaszt kapjanak hamar.

    Mint pl CAPTCHA-t se fogsz irni ujra magadtol, mikor van ra x+1 mukodo peldany, github, lab, akarmi.
    Mutasd a teljes hozzászólást!
  • netangel jol irta. ez alapvetoen hulyeseg, hogy kikuldod a plaintextet..

    most nem azert, de ha mar megirtal egy ilyet, akkor atemelni mennyi? 5 perc?
    gondolom ok se ma kezdtek... a mai sw-ek meg tipikusan copy paste, refactor...
    Mutasd a teljes hozzászólást!
  • Nagy bajok vannak azzal a T betűvel:

    https://mno.hu/belfold/feljelentessel-halalta-meg-a-keretlen-tesztel..

    --[ Egész 20. századért felelős a bűnös T betű. :)
    Mutasd a teljes hozzászólást!
  • Igen, és nem készítünk félmilliárdért olyan rendszert, amely olyan minőségű, amit Pistike kétszázezerért boldogan elkészít. Ez az elmélet.

    De arra próbáltam rámutatni - bár nem értem, ez miért nem evidens -, hogy a helyes jelszókezelés elkészítése jóval-jóval bonyolultabb annál, mint hogy berakunk egy hash függvényt. Ezért maradhatott a jelszó plain text.

    Komolyan nem értem, mit nem lehet ezen érteni.
    Mutasd a teljes hozzászólást!
  • Hali!

    Pont erről beszélek.

    Én meg arról, hogy nem készítünk olyan elfelejtett jelszó funkciót, ami annyiból áll, hogy a jelenlegi jelszót kiküldjük a felhasználó e-mail címére (főleg, ha pénz is van a folyamatban). Tehát, az, hogy plain text-ben tároljuk a jelszót, nem befolyásolja ennek a funkciónak az elkészítési idejét/bonyolultságát… ha megfelelően készítjük el a rendszert. Persze, itt nem erről van szó. 

    Mutasd a teljes hozzászólást!
  • Pont erről beszélek.

    Még egy sima regisztrációs email megerősítésük sem volt. Időhiánnyal küszködtek. Valaki úgy dönthetett, hogy oké, akkor marad a plain text jelszó, ami egyszerűbb és gyorsabb, majd később javítjuk.
    Mutasd a teljes hozzászólást!
  • Ld. netangel válaszát.

    Szerinted melyik az egyszerűbb és gyorsabb? Kiküldeni a plain text jelszót vagy implementálni egy komplett, biztonságos jelszó reset mechanizmust?
    Mutasd a teljes hozzászólást!
  • Hali!

    … viszont onnantól kezdve az elfelejtett jelszó biztonságos kezelését már igen…

    Ez a funkció nem függ attól, hogy hash-t tárolunk a tényleges jelszó helyett. Hacsak az elfelejtett jelszó funkció nem annyiból áll, hogy kiküldjük a felhasználónak a jelenlegi jelszavát (és nem egy tokent – akár URL-lel –, beállítva lejárati időt, vagy egy generált, új jelszót, beállítva, hogy bejelentkezéskor kötelező cserélnie, stb-stb-stb.). 

    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd