Symantec: ? Slå av pcAnywhere nå

[Gjest Slettet-t8fn5F]

Kahuna skrev (På 30.1.2012 den 9.10):

Simen1 skrev (På 28.1.2012 den 22.11):

: Det kan hende at Windows er secure by design, men det må du ta Microsofts ord på. Det er ingen mulighet for å sjekke det selv siden utenforstående ikke får se kildekoden. Ingen innsyn = obskurt.

http://www.microsoft.com/resources/sharedsource/default.mspx

Under MS sitt shared source initiative kan utenforstående under visse forutsetninger få tilgang til koden.

 

Fortsatt ikke helt åpent men heller ikke lukket.

Jepp. Universitetet her i Tromsø var noen av de heldige som fikk kildekoden til Windows 2000...

[sinnaelgen]

Programmering er ikke så enkelt elgen.. Om programmet er sikkert, så har det ingenting å si om kildekoden er tilgjengelig, da selve sjekket skal være sikker og skal ikke kunne være sårbar for noen input utover brukernavn og et passord som er renset for evt. kode som kan kræsje med behandlingen, slik som f. eks sql-injection som er det mest kjente fenomenet.

Poenget mit er hvis man kjenner den fullstendige kilde koden ( også hvordan systemet foretar sjekken) så kan man omgå sikkerheten ved lit kreativ programmering.

Nei, ikke hvis programmet er sikkert. Da har det ingenting å si at kildekoden er åpen. Så lenge det f. eks kjører noe serverprogramvare som en klient skal logge inn på, som kun har en protocol, og kun to inputs (brukernavn, passord), som begge sjekkes for skadelig kode (sql-injection o.l.), så har det ingenting å si om kildekoden er åpen!

 

 

Da er det ikke snakk om hele programkoden.

Her har man jo utelatt den delen som kontrollerer hvem som får adgang ( selv om det er flere programmer ) .

[007CD]

Hmmmm kun ca 15% av Win 2k koden er tilgjengelig for lesning.

Måtte ta en titt og den ligger på havna

[Occi]

Programmering er ikke så enkelt elgen.. Om programmet er sikkert, så har det ingenting å si om kildekoden er tilgjengelig, da selve sjekket skal være sikker og skal ikke kunne være sårbar for noen input utover brukernavn og et passord som er renset for evt. kode som kan kræsje med behandlingen, slik som f. eks sql-injection som er det mest kjente fenomenet.

Poenget mit er hvis man kjenner den fullstendige kilde koden ( også hvordan systemet foretar sjekken) så kan man omgå sikkerheten ved lit kreativ programmering.

Nei, ikke hvis programmet er sikkert. Da har det ingenting å si at kildekoden er åpen. Så lenge det f. eks kjører noe serverprogramvare som en klient skal logge inn på, som kun har en protocol, og kun to inputs (brukernavn, passord), som begge sjekkes for skadelig kode (sql-injection o.l.), så har det ingenting å si om kildekoden er åpen!

Da er det ikke snakk om hele programkoden.

Her har man jo utelatt den delen som kontrollerer hvem som får adgang ( selv om det er flere programmer ) .

Jo, man kan dele hele kildekoden så lenge selve sjekken er sikker. Selve logindataene er ikke regnet som kildekode, dvs. du deler da selvsagt ikke databasen. Selve sjekken opp mot databasen kan godt også deles, da det skjer gjerne på serverside, så det har ingenting å si om du deler det. Du er pent nødt til å lese deg opp på emnet om du skal kunne forstå dette, noe du åpenbart ikke gjør.

[sinnaelgen]

Det virker som du ikke helt forstår tenkegangen min her.

 

Slik du påstår det er så er det ikke mulig at man er så sikker kun med å lese data , når behandlingen av dem er åpen for enhver.

 

Så lenge man har kilde koden til behandlingsmåten så kan man også gå motsatt vei og dekode dataene.

 

 

 

Hvis du tenker på en slags form for kryptering så er det sjeldent at krypteringskoden er kjent , bare dataene.

[Occi]

Jeg forstår absolutt tankegangen din, det er bare det at den er feil.

 

Så lenge man har kilde koden til behandlingsmåten så kan man også gå motsatt vei og dekode dataene.

Nå er jeg veldig interessert i å høre hva "motsatt vei og dekode dataene" betyr. Hvordan system er det egentlig du ser for deg? En ordentlig kryptering med salt er ikke bare å "dekode"..

 

Endret 30. januar 2012 av Occi

[sinnaelgen]

Nå er det veldig lett å påstå at man forstår tenkegangen til en eller annen og samtidig på stå et man tar feil.

 

 

 

Det jeg tenkte på var at når man skal sammenligne f.eks passordet man skriver inn og det man er registrert med så må jo systemet hente frem begge passorden på en eller annen måte for å sammenligne.

det kan man gjøre på mange måter . uansett så ander man opp med to datablokker som må sammenlignes.

 

kjenner man til hvordan disse passordene blir satt like så kan også dekode det registrerte passordet.

 

skulle man likevel ikke få det til så kan man unngå hele godkjenningen og i stedet hente inn det registrerte passordet .

 

i første omgang er det ikke sikkert man får det til å stemme med rette passordet . men da har man muligheten til å lage seg en generator som sammenligner det generte passordet og det registrerte. her snakker jeg om et helt separat program.

Da er det jo bare å la denne generatoren kjøre til man har fått frem to passord som er like

 

Man har også muligheten til forsøke helt til passordet blir godkjent.

Riktignok er det mangge systemer som begrenser antall forsøk , men hvis man venter en stund så kan man forsøke igjen.

 

 

jeg her ikke prøvd selv , jeg har heller ingen interesse av det men ser faremomentet her

 

 

jeg kunne være interessert i vite hvorfor du mener det fungerer ( prinsippet bak ) ,slik det jeg sier ikke er mulig

[Occi]

kjenner man til hvordan disse passordene blir satt like så kan også dekode det registrerte passordet.

Nei, en slik sjekk gjøres gjerne ved at når passordet lagres i første omgang så krypteres input, og når det da sjekkes seinere så krypteres input igjen, deretter sjekkes de opp mot hverandre. Passord lagres ikke i klartekst i et sikkert system. En ordentlig kryptering er ikke å bare å "dekode" som du selv sier om kyrpteringen og passordet er sterkt (som man selvfølgelig må ta utgangspunkt i, hvis ikke kan man ikke si at systemet sikkert i utgangspunktet).

 

skulle man likevel ikke få det til så kan man unngå hele godkjenningen og i stedet hente inn det registrerte passordet .

Om du kan unngå godkjenningen er ikke systemet sikkert, og derfor er det helt uvesentlig. Igjen, et ordentlig system med kun en protocol og to inputs (brukernavn og passord), så er det ingen annen måte å kommunisere med aktuelle program på server. Alt annet vil tilsi dårlig system/kode.

 

i første omgang er det ikke sikkert man får det til å stemme med rette passordet . men da har man muligheten til å lage seg en generator som sammenligner det generte passordet og det registrerte. her snakker jeg om et helt separat program.

Da er det jo bare å la denne generatoren kjøre til man har fått frem to passord som er like

En slik fremgangsmetode tar utgangspunkt i dårlig kryptering og dårlig passord, noe som bryter med hva man kan kalle et sikkert system, og derfor har det igjen ingenting å si om kildekoden er åpen. Et dårlig system med som benytter dårlig kryptering vil selvfølgelig lide av at krypteringsmetoden blir offentliggjort, men om du bruker sha256 eller andre sterke krypteringer så har det ingenting å si om det lekker.

 

Riktignok er det mangge systemer som begrenser antall forsøk , men hvis man venter en stund så kan man forsøke igjen.

Kritiske systemer benytter seg av forsvarsmekanismer mot bruteforcing.

 

jeg her ikke prøvd selv , jeg har heller ingen interesse av det men ser faremomentet her

Det er ikke noe faremoment om systemet satt opp ordentlig.

 

jeg kunne være interessert i vite hvorfor du mener det fungerer ( prinsippet bak ) ,slik det jeg sier ikke er mulig

Det er fordi du beskriver et system som ikke er sikkert, og bryter derfor med hele diskusjonen rundt om at om et system er sikkert, kan like godt kildekoden gis ut.

[sinnaelgen]

når jeg sier hele koden så mener også koden for å krypteringen .

kjenner man den blir det mye enklere å genere passord.

 

De vil metoden jeg beskrev fungere.

 

hvis du ikke fikke med deg alt :

 

Man får først tak i passordet som er kryptert

Så bruker man denne generatoren for lage nye passord som er krypter etter samme metode

Det er disse ( det generte og det registrerte passordet) som sammenlines .

Begge er da kryptert

 

man har ikke dekodet , men forsøkt med mange passord som til slutt passer med det originale.

Dette funger fordi man bruker samme metode for så sjekke ut passorden som systemet bruker for å kontrollere passordet.

 

Hvis det skal være sikkert så kan man ikke både vite det krypterte passordet og metoden for generere det.

 

Etter dette så begynner du sikker å snakke om krypteringnøkler.

 

Hvor mange systemer bruker dobbel ,trippel eller anda flere ganger kryptering ?

 

Det vil heller ikke hjelpe hvis man vet hvordan man skal lage koden samtidig som man har det kodete passordet

[Occi]

når jeg sier hele koden så mener også koden for å krypteringen .

kjenner man den blir det mye enklere å genere passord.

At du kan genere passordene på lik måte som i en login er likegyldig såfremt krypteringen og passordet er sterkt. Det vil ta flere tusen, om ikke millioner av år å matche et godt passord som ikke står i en ordliste som er kryptert med en god kryptering. Statistisk sett, selvfølgelig.

 

Man får først tak i passordet som er kryptert

Så bruker man denne generatoren for lage nye passord som er krypter etter samme metode

Det er disse ( det generte og det registrerte passordet) som sammenlines .

Begge er da kryptert

 

man har ikke dekodet , men forsøkt med mange passord som til slutt passer med det originale.

Dette funger fordi man bruker samme metode for så sjekke ut passorden som systemet bruker for å kontrollere passordet.

Jeg er klar over hvordan bruteforcing fungerer, men bruteforcing fungerer ikke på systemet som er godt sikret, enkelt og greit.

 

Hvis det skal være sikkert så kan man ikke både vite det krypterte passordet og metoden for generere det.

Selv om noe er åpen kildekode så deler man ikke det krypterte passordet helt uten videre, men selv om det skulle komme på avveie så vil det allikevel være usannsynlig at du klarer å dekryptere det om det er som nevnt så mange ganger før; god kryptering og godt passord. Bruker du salt i tillegg blir det virkelig vanskelig (tatt utgangspunkt at denne heller ikke lekker selvsagt, om passord+salt lekker så er det noe annet galt med systemet ditt).

 

Hvor mange systemer bruker dobbel ,trippel eller anda flere ganger kryptering ?

Hvordan er det relevant? Det holder med en god kryptering og et godt passord.

 

Det vil heller ikke hjelpe hvis man vet hvordan man skal lage koden samtidig som man har det kodete passordet

Jo, for selv om du har det krypterte passordet så veit du ikke hva det er. Igjen så referer jeg til at med en god kryptering og et godt passord så er heller ikke dette en sikker inngangsbillett.

 

 

 

For å oppsummere det hele veldig enkelt: I et sikkert system med godt passord, god kryptering og gjerne også salt, så kan du bruteforce det i evigheter, noe du uansett ikke vil få lov til om systemet er godt sikret (hindrer bruteforcing), uten at du kommer noen vei. Gode krypteringer tar tilnærmet evig tid i forhold til en mannsalder.

[xibriz]

når jeg sier hele koden så mener også koden for å krypteringen .

kjenner man den blir det mye enklere å genere passord.

 

De vil metoden jeg beskrev fungere.

 

hvis du ikke fikke med deg alt :

 

Man får først tak i passordet som er kryptert

Så bruker man denne generatoren for lage nye passord som er krypter etter samme metode

Det er disse ( det generte og det registrerte passordet) som sammenlines .

Begge er da kryptert

 

man har ikke dekodet , men forsøkt med mange passord som til slutt passer med det originale.

Dette funger fordi man bruker samme metode for så sjekke ut passorden som systemet bruker for å kontrollere passordet.

 

Hvis det skal være sikkert så kan man ikke både vite det krypterte passordet og metoden for generere det.

 

Etter dette så begynner du sikker å snakke om krypteringnøkler.

 

Hvor mange systemer bruker dobbel ,trippel eller anda flere ganger kryptering ?

 

Det vil heller ikke hjelpe hvis man vet hvordan man skal lage koden samtidig som man har det kodete passordet

 

Hele grunnlaget du baserer din diskusjon på er feil.. det er kildekoden som er lekket, ikke DB/fil med passord.

 

Derfor har du kanskje metoten passordet krypteres etter, men ingenting å sammenligne det med.

[Gjest Slettet-t8fn5F]

Det virker som du ikke helt forstår tenkegangen min her.

 

Slik du påstår det er så er det ikke mulig at man er så sikker kun med å lese data , når behandlingen av dem er åpen for enhver.

 

Så lenge man har kilde koden til behandlingsmåten så kan man også gå motsatt vei og dekode dataene.

 

 

 

Hvis du tenker på en slags form for kryptering så er det sjeldent at krypteringskoden er kjent , bare dataene.

Har du noen som helst erfaring eller kunnskaper om programmering og systemutvikling?

[sinnaelgen]

jeg har en del erfaring med programmering , men ingen som har direkte med systemer å gjøre.

 

jeg tror at der ignorerer en del ting her.

For å oppsummere , jeg skal forsøke å være kort.

 

 

Jeg har en viss forståelse på hvordan det fungerer.

 

1 man logger seg inne med passord og andre loging parameter.

2 programmet vi mest sannsynlig omkode det man tater inne og sammenligne det men data som er lagret som en del av din bruker registrering

3 når disse matcher hverandre så har systemet godkjøpet at du er innlogget .

 

Det jeg forutsetter ar at absolutt alt av kode til systemet er tilgjengelig ( det sies at det er det for frie programmer ) så ser man jo også hvordan programmet jobber.

 

Da finner man også ut hvordan innlogging dataene blir behandlet .

og ikke minst man kan finne ut hvor passordet og andre data blir plassert .

 

Da kan man plukke ut passordet utenfor systemet ( man trenger ikke systemet i det hele tatt ) .

 

Så lager man sit eget program som gjør nøyaktig det samme som systemet gjør for å klargjøre inn-log dataene man har tastet inn

forsatt bruker man ikke systemet.

 

Til slut er det jo bare for det programmet man selv har laget å sammenligne passorden o.s.v som man har funne med noen man selv har generert.

gjør man det mange nok ganger så finner man ut hva inn log dataene er .

 

Da først kan man bruke systemet og skrive inn de dataene som matchet .

 

 

Når alt dette er oppfylt så kan jeg ikke se hvordan man kan unngå det uansett hvor mange sikkerhetsrutiner som er innebygget

 

At dette kan være vanskelig er dog ikke spørsmålet , kun at det er mulig

[Gjest Slettet-t8fn5F]

Hva har du da programmert i og til hva?

[sinnaelgen]

Hva har du da programmert i og til hva?

 

Delphi ( pascal) til hjemme bruk.

 

Det har gått mest i prøve ut en del ting , men jeg planlegger å lage meg en database men sliter litt der

Detaljene får du ta et annet sted

[Gjest Slettet-t8fn5F]

Vel det er en helt verden i forskjell å sitte hjemme å fidle litt, til å ha en utdannelse og jobbe med programmering.

Jeg slo en spiker i et tre, er jeg da snekker?

[Occi]

["forklaring" for hvordan man kan hacke et system man kjenner koden til]

Du skisserer et system som ikke er sikkert. Det er hele utgangspunktet i en diskusjon om at åpen kildekode er sikkert. At det finnes usikker kode er ikke noe nytt, hverken når det gjelder lukket eller åpen kildekode. Det du skisserer er ikke sikkert om du selv kan skrive et eget program som kan koble seg opp mot databasen..

[sinnaelgen]

["forklaring" for hvordan man kan hacke et system man kjenner koden til]

Du skisserer et system som ikke er sikkert. Det er hele utgangspunktet i en diskusjon om at åpen kildekode er sikkert. At det finnes usikker kode er ikke noe nytt, hverken når det gjelder lukket eller åpen kildekode. Det du skisserer er ikke sikkert om du selv kan skrive et eget program som kan koble seg opp mot databasen..

 

På det punktet er vi ening.

 

Det du forsøker å fortelle meg er at lignede system er mye mere sikkert selv om de samme forholdene foreligger.

 

Det jeg har forsøkt å fortelle her er at ingen systemer er sikkert så lenge man har full kontroll over absolutt all programkoden som må til for at program et eller systemet skal fungere.

 

 

Nå går det helt fint å lege programmer ute at man har 100% kontroll over alle koden som brukes ( dette gjelder spesielt subrutiner og delprogrammer ) .

Men da nakker man også om systemer der deler av koden er ukjent , som blir noe annet.

Da er det sikkert

[Occi]

["forklaring" for hvordan man kan hacke et system man kjenner koden til]

Du skisserer et system som ikke er sikkert. Det er hele utgangspunktet i en diskusjon om at åpen kildekode er sikkert. At det finnes usikker kode er ikke noe nytt, hverken når det gjelder lukket eller åpen kildekode. Det du skisserer er ikke sikkert om du selv kan skrive et eget program som kan koble seg opp mot databasen..

På det punktet er vi ening.

Litt usikker på om vi er det egentlig.

 

Det jeg har forsøkt å fortelle her er at ingen systemer er sikkert så lenge man har full kontroll over absolutt all programkoden som må til for at program et eller systemet skal fungere.

Jo, man kan lage et system som er sikkert selv om kildekoden er sikker. Dette er spesielt vanlig og enkelt å skissere om det foregår noen behandling av brukerinput på en server. Koden som foregår på serverside kan jo ikke påvirkes selv om du kjenner til kildekoden, så det har ingenting å si om du kjenner den såfremt den ikke har noen sikkerhetshull.

 

Nå føler jeg at jeg gjentar meg selv for mye her, så jeg gidder ikke forklare hvorfor enda en gang. Saken er rett og slett at det har ingenting å si hva du f. eks forer et program som kjører på en server om den sjekker om inputen er gyldig og sikker, all behandlingen foregår uansett lokalt på server og er ikke mulig å påvirke om koden er sikker.

 

Nå går det helt fint å lege programmer ute at man har 100% kontroll over alle koden som brukes ( dette gjelder spesielt subrutiner og delprogrammer ) .

Men da nakker man også om systemer der deler av koden er ukjent , som blir noe annet.

Da er det sikkert

Hele koden kan gjerne være kjent i de aller fleste tilfeller om koden ikke kan påvirkes, mao. den er sett på som sikker.

 

 

[sinnaelgen]

Er du klar over at man kan lage kloner av programmer hvis man kjenner til alt av kilde kode ?

 

Da lager man et program som lurer serveren til å tro at det er det ekte programmet som kjører .

Den enste forskjellen er her at klonen oppfører seg alt annet en normalt .

 

Bruker man klient server metoden slik du beskriver så kjenner man ikke til alt av kode.

 

jeg tro du misforstår meng når jeg sier absolutt alt av programkode som er i bruk

 

nå er det neppe vanlig at de som programermer slike systemer faktisk for tilgang til alt av kode heller