Utroligt at PBS, som var ejet af bankerne (AFAIK), kunne foreslå en applet-baseret løsning.
Bankernes IT-leverandører (og herunder ikke mindst BEC) har siden slutningen af 1990'erne vidst hvor meget bøvl der er med applet-baserede browserløsninger...
Det er også i praksis almindeligt at brugernavne og kodeord sendes over en ukrypteret linie...
Okay, jeg skulle have været mere præcis. Når jeg skriver "drift" tænker jeg "drift i samarbejde med en Hosting Provider (HP)". Det er ikke det samme som at der ikke er drift-relaterede opgaver...
Forskellige HP'er har forskellige tilgange til SSL. Hos nogen er det dyrt og besværligt, hos andre er det nemt og stort set gratis.
Hvis din HP terminerer SSL'en på en load-balancer i DMZ'en (eller tæt på), så er trafikken sandsynligvis ukrypteret på bagsiden af denne. Det betyder så blot at du skal have tillid til din HP. Men det skal du jo alligvel, for det er jo der databasen med alle de saltede og hashede kodeord ligger :-) Hvilket jo så ikke hjælper dig hvis dine kodeord drøner ukrypteret over en intern forbindelse hvor en kriminel (eller blot lettere anløben medarbejder, betalt af Se & Hør f.eks.) lytter med... For slet ikke at nævne log-filer...
Sikkerhed er sq svært, så lad nu være med at pege fingre af andre der måske ikke lige har fået det helt korrekt første gang. Det bygger i høj grad på tillid - som PHK er inde på andre steder - tillid til dem eller de der har de rigtig interessante adgange; om det så er til databaser, netværk eller anden infrastruktur.
Og som jeg for snart længe siden forsøgte at argumentere for, så er der situationer hvor det ikke er super-vigtigt at sikkerheden er som i... Lad mig se... Bankerne?
Du kan købe et single-site SSL certifikat for ~200 kr. om året. Nok ikke lige noget der vælter en forenings budget.
Jeg gentager:
Mine erfaringer med "drift" af hjemmesider i små foreninger siger mig at "omkostninger" er mange ting. At man kan få SSL certifikater gratis er ikke det samme som at det er uden omkostninger at implementere og drifte.
Det er i øvrigt ofte en udfordring blot at finde én i bestyrelsen - eller dennes omgangskreds - som magter drift/vedligehold af hjemmesider...
Det kræver en del disciplin at anvende floating-point korrekt, og det er desværre ret nemt at fucke up...
Enig. Faktisk er floats helt og aldeles uegnede til decimaltalsaritmetik. Hvis altså man interesserer sig for at summen af en stribe tal passer på sidste decimal, og på dette område er regnskabsfolk så underligt krakilske...
At bruge floats som 54-bit integers kræver godtnok man holder tungen lige i munden. En enkelt "hurtig" eller uerfaren progammør der lige kommer forbi med en mindre rettelse og din (64-bit)float er ikke længere en 54-bit integer...
Det kunne være interessant at få lidt feedback fra folkene bag Billy's Billing om hvordan de konkret løser den slags udfordringer...
Så det bliver efter min mening ikke en sikker løsning og næsten lige så slemt, som at sende adgangskoder over http.
Glimrende! Vi er enige!
Jeg har aldrig påstået det var sikkert og vi er enige om at det (kun) næsten er ligeså slemt som at sende adgangskoder over HTTP.
Det minder mig om at jeg da har alvorlige problemer med mine WordPress-drevne blogs som kører HTTP og hvor brugernavn/adgangskode sendes over HTTP i klartekst...
Jeg behøver ikke din adgangskode - hashværdien er nok :-)
Du misforstår min pointe. Har du adgangskoden (eller dennes hash) kan du logge på, ja.
Men ved hashing sendes adgangskoden ikke i klartekst... Så hvis du opsnapper min hash, ved du ikke nødvendigvis hvad min adgangskode var... Og hvis jeg har brugt den samme adgangskode i min bank er du ikke tættere på... Er vi enige her?...
At MD5 så er en skod-hash er en anden detalje. Men det kan jo være man kan sige det samme om SHA-512 om nogle få år...
Mine erfaringer med "drift" af hjemmesider i små foreninger siger mig at "omkostninger" er mange ting. At man kan få SSL certifikater gratis er ikke det samme som at det er uden omkostninger at implementere og drifte. Det er i øvrigt ofte en udfordring blot at finde én i bestyrelsen - eller dennes omgangskreds - som magter drift/vedligehold af hjemmesider...
Tjah, som nævnt, man kan argumentere for om ikke det burde køre over SSL...
Når det så er sagt. Har du først valgt MD5 hashing i klienten, er det svært at ændre uden at forlange at alle brugere ændrer deres kodeord :-)
Nu kan man argumentere for om ikke informationerne i det pågældende system af og til kan være så følsomme at forbindelsen derfor burde være via SSL.
Og lad nu være med at antage noget om hvor dårligt de sandsynligvis har implementeret sikkerheden server-side. Det ved du vel reelt ikke noget om?
Jeg synes client-side hashing er udemærket. I systemer som ikke arbejder med følsom information - det kunne f.eks. være svømmeklubbens holdtilmeldingssystem - hvor SSL ikke er nødvendigt og hvor administration af og omkostninger til SSL kan være uden for foreningens muligheder, der er det en udemærket work-around til at undgå at brugernes kodeord kommer over linien i klartekst.
...en større del af testarbejdet med at finde fejl i koden lægges i hænderne på programmørerne.
Isoleret lyder det som en rigtig dårlig idé. Hvis programmørerne ikke i forvejen laver unit-tests er det da på tide de lærer det. Men unit-tests kan ALDRIG afløse rigtige end-user tests af uddannede testere!
Prøv f.eks at spørge en UNIX, en Windows og en Mainframe sysadm om "versionskontrol"
Superrelevant spørgsmål!
Jeg var for nogle år siden på et, slet ikke uinteressant, projekt hvor der sideløbende blev udviklet i JAVA på den decentrale og PL/1 på mainframen.
Denne organisation havde valgt det mest grotesk ringe SCM værktøj jeg nogensinde har været udsat for. Det gjorde det ikke bedre at man selv havde udviklet udvidelser til dette, og vi som brugere kun kunne få support på de ofte temmelig mange problemer der var, hvis mindst én af de 2 rødder der havde udviklet disse, var på arbejde...
Argumentet var efter sigende, at SCM'en også kunne bruges til at håndtere mainframens PL/1 kode.
Ironien er så - ihvertfald mens jeg var på projektet - nægtede PL/1 programmørerne at bruge dette SCM. Den slags pjat var de vist ikke vant til.
Enig...
Bureaukrater der udtænker den slags vanvid bør skydes langsomt med lunken lort ved daggry (de er ikke værd at bruge krudt på)...
Fuldstændig idiotisk. Tager sig sikkert fint ud i et regneark med flere faner og præsenteres flot i en powerpoint med lagkager og jeg-skal-komme-efter-dig-skal-jeg.
Men hvorfor er der ingen der siger fra?
Jeg græmmes...
Jeg går ind for KISS. I det hele taget har jeg aldrig fattet hvorfor Hovedstadsområdet (hvor jeg primært bruger OT) er delt op i jeg ved ikke hvor mange zoner, når f.eks. London kan klare sig med... 6...
Er der ikke nogen der kunne være venlige at gå gennem SCM'ens history og finde ud af hvem der har commit'et den "fejl"?
De har simpelthen brug for standard rapporter til at give dem firma nøgletal. Det er skrammende men det er hvad jeg har hørt fra flere steder.
Det er meget skræmmende, for rygter vil vide at krav til levering af KPI's og tilsvarende fra systemet til beslutningstagerne ofte overskygger ønsker og forventninger til UI/UX og derfor kan være direkte ødelæggende for selv de mest velmenene systemer...
Men det er også nogen gange det systemer bliver solgt på. Altså: "Hvis vi implementerer dette geniale standardsystem fra leverandør XXX, så kan vi få direkte indblik i den aktuelle økonomiske situation og vi kan til enhver tid udpege nøgleprodukter hvor vi bør kunne optimere indtjening/omkostninger. Den tænkte effektivisering i kroner og ører forventes at kunne tjene investeringen hjem på Y år".
Og så er den sådan set ikke længere.
Jamen så byd ind...
Jeg er kun mig og kunne ikke drømme om at byde ind med andet end Time & Material.
Når det er sagt tror jeg ikke vi er så uenige. Den grundlæggende udfordring er "De Offentlige Kontrakter" som giver anledning til big-bang udbud i 2-3 cifrede mio kontrakter. Som kun de største magter at byde ind på. De har ganget med et sted mellem kvadratrod 2 og pi for at være på den sikre side, ellers er fastpris ganske enkelt no-go. I det konkrete tilfælde er det Steria. De har nok snarere håbet på nogle lukrative servicekontrakter efterfølgende...
Og det ender galt HVER gang. Derfor må der gøres op med hele konceptet, for big-bang projekter er dømt til at gå galt.
Alt efter hvilke lovkrav der skal opfyldes for at lave systemet, så kan det meget hurtigt komme til at koste rigtig mange penge, for selv simple systemer.
Hmmmthahh, der kommer an på. Og det gælder vel også tilpasningerne til "standardsystemerne"?
Der er ikke meget der slår små simple systemer på driftssikkerhed, så den køber jeg heller ikke umiddelbart.Der skal heller ikke mange krav til driftsikkerhed ...
kan det aldrig koste over 100 millioner, det er et 2-mands projekt, som kan laves af studerende i fritiden, på mindre end 1 år
Meget enig. Det er helt vildt hvad et lille team af dedikerede udviklere kan afstedkomme på få måneder!
Udfordringerne opstår imidlertid når systemet som er designet til udskrive badebilletter også skal interface til leverandøren af klaphatte, producere farvestrålende rapporter til direktionen og sende fakturaer til det offentlige.
Derfor kan det være fristende at købe et standardsystem - som har "connectors" til hvadsomhelst og kan tilpasses i det uendelige - og så bruge tid og penge på at tilpasse det, fremfor at forsøge at ny- eller videreudvikle det oprindelige på baggrund af de nye krav. Desværre.
For ofte viser tilpasningerne sig at være sværere og dyrere end antaget, de der "connectors" koster dyre ekstralicenser, producenten har lovet for meget og tilpasningerne giver problemer når der skal opgraderes til nyere versioner, hvilket er påkrævet hvis man ikke ønsker fortsat support skal være urimelig omkostningstung. Og så videre.
Ved sgu snart ikke...
Jeg er varm fortaler for at man laver projekter hvor man prøver "nyt" af: ny teknologi, metoder, infrastruktur osv.
Men start dog for pokker med en Proof-of-Concept, en pilot eller lignende. Lav løbende evalueringer og vær klar til at smide barnet ud med badevandet for der er stor risiko for at det ikke er levedygtigt første gang...
Alt andet er temmelig hovedløst. Eller noget...
Hvis man man ikke kan stave korrekt dansk, hvor stor er chancen så for at skrive korrekt programkode...
...og hvis den slags teser skulle holde vand ville det ikke give mening at outsource til Ukraine, Indien og den slags...
Jesper Udby