Kommentarer til pcrypt.org
Benny Nissen
Har i lang tid arbejdet på en online password database løsning
som hobby og vil meget gerne have jeres ris og/eller ros på dette
arbejde.
http://pcrypt.org eller pcrypt.dk
Der mangler stadig lidt indhold og arbejder stadig på den Danske
oversættelse, men ellers burde det snart være klart.
Mvh
Benny
--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
Birger Sørensen
> Hej
>
> Har i lang tid arbejdet på en online password database løsning
> som hobby og vil meget gerne have jeres ris og/eller ros på dette
> arbejde.
>
> http://pcrypt.org eller pcrypt.dk
>
> Der mangler stadig lidt indhold og arbejder stadig på den Danske
> oversættelse, men ellers burde det snart være klart.
>
> Mvh
> Benny
Man skal have en konto for at kunne se noget?
Hvor er det, at sikkerheden er større, ved at have sine password
liggende i en online database man ikke har kontrol over, end at have
dem i "gamle emails" - eller et andet sted man selv har kontrol over?
Hvordan får jeg fat i mine passwords når/hvis den server der betjener
den online database er nede (Murpys lov siger, at den er nede når jeg
har brug for den!).
Men ellers da, en god idé.
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk
Henrik Eriksen
news:4de0db94$0$315$1472...@news.sunsite.dk...
> Hej
>
> Har i lang tid arbejdet på en online password database løsning
> som hobby og vil meget gerne have jeres ris og/eller ros på dette
> arbejde.
>
> http://pcrypt.org eller pcrypt.dk
>
> Der mangler stadig lidt indhold og arbejder stadig på den Danske
> oversættelse, men ellers burde det snart være klart.
>
> Mvh
> Benny
Den er faktisk ret flot efter min mening. Virker proffet.
Jeg er ikke stiv i webprogrammering, så min kommentar er kun mht design:
Hængelåsen i stedet for "D" i PASSWORDCRYPT skulle være i stedet for "O",
ikke "D".
Den minder lidt om et "O", og på ingen måde om et "D".
Knapperne øverst til "PASSWORDS", "GROUPS", "ACCOUNT", etc. burde reagere
(ændre udseende) når man fører musen hen over dem. Også når man klikker
("museknap-ned"-funktion).
Og så lige den småting, at jeg ikke tror jeg selv ville gemme mine passwords
på nettet.
Benny Nissen
>
> Man skal have en konto for at kunne se noget?
> Hvor er det, at sikkerheden er større, ved at have sine password
> liggende i en online database man ikke har kontrol over, end at have
> dem i "gamle emails" - eller et andet sted man selv har kontrol over?
> Hvordan får jeg fat i mine passwords når/hvis den server der betjener
> den online database er nede (Murpys lov siger, at den er nede når jeg
> har brug for den!).
> Men ellers da, en god idé.
>
> Birger
Tja ideen er da at man skal oprette en konto for at se noget brugbart -
ens egne indtastninger af adgangskoder etc.
Du kan selvfølgelig ikke få adgang til dine passwords når serveren er
nede, men jeg har gjort meget for at eksport(backup) og import er muligt,
så man opnår en hvis fleksibilitet.
Jeg vil påstå at det er mere sikkert at placere sine passwords i dette
system end i mange alternative løsninger. Det er i hvert fald mere
fleksibelt.
Rent faktisk foregår alt krypteringen/logik i javascript kode (client
side) og server er egentlig kun til design og lager. Så det er egentlig
en "sikker" cloud løsning. Alle kan ligeledes kontrollere det ved at
kikke på javascript koden (selvfølgelig kun for eksperter).
Benny Nissen
>
> Den er faktisk ret flot efter min mening. Virker proffet.
>
> Jeg er ikke stiv i webprogrammering, så min kommentar er kun mht design:
>
> Hængelåsen i stedet for "D" i PASSWORDCRYPT skulle være i stedet for "O",
> ikke "D".
> Den minder lidt om et "O", og på ingen måde om et "D".
>
> Knapperne øverst til "PASSWORDS", "GROUPS", "ACCOUNT", etc. burde reagere
> (ændre udseende) når man fører musen hen over dem. Også når man klikker
> ("museknap-ned"-funktion).
>
> Og så lige den småting, at jeg ikke tror jeg selv ville gemme mine passwords
> på nettet.
>
Tak for roserne. Fik en grafikker til at lave det overordnede design og logo.
De kommentarer du kommer med har jeg faktisk selv overvejet flere gange og vil
nu kikke på det!
Logo med D og O tror jeg ikke jeg ændre da jeg så sikkert skal have fat i
grafikkeren igen etc. Synes heller ikke lige den del er helt så slem. At det er
D er sikkert også for at markere deling af ord Password|Crypt med forskellige
farver.
Det er tosset at folk har den indstilling at de ikke vil gemme deres password på
nettet. Det er meget mere logisk og praktisk og faktisk årsagen til at jeg har
lavet dette site. Har forsøgt at lave det således at folk får tillid til det og
tror på at det er sikkert. Bl.a. også årsagen til at det er Open Source.
Alternativet er at man altid skal rende rundt med dem på en USB nøgle med risiko
for at tabe den. Anvende et specielt program der kun virker på den PC hvor det
er installeret o.s.v.
Tror også det er mere sikkert at placere dem på en krypteret server hvor der er
"prof" backup og du kan få adgang til dem alle steder hvor der er en internet
forbindelse.
En ting er sikkert - der kommer flere og flere passwords man skal huske så der
bliver mere og mere behov for en løsning hvor man kan få adgang til dem alle
steder.
Det jeg på en eller anden måde skal have fortalt og overbevist folk om er at
deres passwords virkelig er sikre og ingen andre kan få adgang til dem, selv om
de ligger i skyen og det er ikke en nem opgave som jeg stadig overvejer - så
hvis du har nogen ideer?
Begge indlæg indtil videre lukker jo også den holdning ud med det samme - jeg
ligger ikke mine passwords på nettet!
Jeg har den påstand at her er det sikkert. Alt logik foregår i browseren
(javascript) der i sagens natur kan kontrolleres af folk med forstand på
javascript. Ingen passwords forlader browseren med mindre det er AES krypteret.
Master password findes kun i browseren, det bliver aldrig overført til server på
nogen måde.
Birger Sørensen
> Birger Sørensen wrote in dk.edb.internet.webdesign.ris+ros:
>>
>> Man skal have en konto for at kunne se noget?
>> Hvor er det, at sikkerheden er større, ved at have sine password
>> liggende i en online database man ikke har kontrol over, end at have
>> dem i "gamle emails" - eller et andet sted man selv har kontrol over?
>> Hvordan får jeg fat i mine passwords når/hvis den server der betjener
>> den online database er nede (Murpys lov siger, at den er nede når jeg
>> har brug for den!).
>> Men ellers da, en god idé.
>>
>> Birger
>
> Tja ideen er da at man skal oprette en konto for at se noget brugbart -
> ens egne indtastninger af adgangskoder etc.
>
> Du kan selvfølgelig ikke få adgang til dine passwords når serveren er
> nede, men jeg har gjort meget for at eksport(backup) og import er muligt,
> så man opnår en hvis fleksibilitet.
Altså beder du os om at oprette en konto, for at kunne give dig
feedback?
Eller - hvad er det egentlig du spørger om?
> Jeg vil påstå at det er mere sikkert at placere sine passwords i dette
> system end i mange alternative løsninger. Det er i hvert fald mere
> fleksibelt.
>
> Rent faktisk foregår alt krypteringen/logik i javascript kode (client
> side) og server er egentlig kun til design og lager. Så det er egentlig
> en "sikker" cloud løsning. Alle kan ligeledes kontrollere det ved at
> kikke på javascript koden (selvfølgelig kun for eksperter).
Alt hvad der foregår i js, er udelukkende for "brugervenlighed"
Hvis kryptering af data foregår i js, er det ikke arbejdet med at
skrive koden værd, og i hvert fald ikke sikkert på nogen måde.
Lige præcis fordi man kan se det hele i js koden, er det en smal sag
for dem der vil ødelægge dit arbejde - evt. stjæle andres passwords.
Hvad går dem der slår js fra?
Benny Nissen
> > ens egne indtastninger af adgangskoder etc.
> >
> > Du kan selvfølgelig ikke få adgang til dine passwords når serveren er
> > nede, men jeg har gjort meget for at eksport(backup) og import er
muligt,
> > så man opnår en hvis fleksibilitet.
>
> Altså beder du os om at oprette en konto, for at kunne give dig
> feedback?
> Eller - hvad er det egentlig du spørger om?
Jeg beder jer ikke om at oprette en konto, men ja - man kan da give bedre
feedback hvis man opretter en konto. Men det er da intet krav for at give
feedback - så kan man bare næsten kun give feedback på design overordnet
set.
Jeg beder om feedback på funktionallitet, design, brugervenlighed etc.
>
> > Jeg vil påstå at det er mere sikkert at placere sine passwords i dette
> > system end i mange alternative løsninger. Det er i hvert fald mere
> > fleksibelt.
> >
> > Rent faktisk foregår alt krypteringen/logik i javascript kode (client
> > side) og server er egentlig kun til design og lager. Så det er egentlig
> > en "sikker" cloud løsning. Alle kan ligeledes kontrollere det ved at
> > kikke på javascript koden (selvfølgelig kun for eksperter).
>
> Alt hvad der foregår i js, er udelukkende for "brugervenlighed"
> Hvis kryptering af data foregår i js, er det ikke arbejdet med at
> skrive koden værd, og i hvert fald ikke sikkert på nogen måde.
> Lige præcis fordi man kan se det hele i js koden, er det en smal sag
> for dem der vil ødelægge dit arbejde - evt. stjæle andres passwords.
> Hvad går dem der slår js fra?
Der er jeg altså meget uenig med dig! I dag kan man godt anvende javascript
til meget andet end brugervenlighed hvilket jeg mener jeg her efterviser.
Hvorfor skulle det ikke være sikkert fordi det er lavet i javascript? Ja
alle kan se koden, men det er ikke herfra sikkerheden kommer ved kryptering.
Det er faktisk bedst at man kan se koden. Så længe man ikke kan se password
anvendt til krypteringen er det sikkert.
Hvis jeg har lavet en fejl i implementeringen og det er muligt for nogen at
sende noget skadeligt javascript til ens egne side kan man stadig ikke se de
andres passwords på nogen måde (man har ikke deres master password).
Sikkerheden er først for alvor i fare hvis nogen kan ændre den javascript
der sendes ud til alle browsere. Det kræver så at de har adgang til server
eller laver et "man in the middle attack" (noget SSL vil beskytte imod). Men
stadig vil det være detekterbart for eksperter at dette er sket (fordi de
kan se alt koden).
Birger Sørensen
Roser har torne.
Jeg er enig med dig, så langt, at der bliver flere og flere passwords
der skal huskes.
Og den her er jeg også enig i : "Har forsøgt at lave det således at
folk får tillid til det og tror på at det er sikkert."
Faren er, at der er nogen der fatter tillid, og tror på det. For det er
ikke sikkert, når det forgår i js.
Benny Nissen
>
> Jeg er enig med dig, så langt, at der bliver flere og flere passwords
> der skal huskes.
> Og den her er jeg også enig i : "Har forsøgt at lave det således at
> folk får tillid til det og tror på at det er sikkert."
> Faren er, at der er nogen der fatter tillid, og tror på det. For det er
> ikke sikkert, når det forgår i js.
>
> Birger
Intet er absolut sikkert. Hvad der er lavet af mennesker kan også nedbrydes af
mennesker - i hvert fald over tid.
Se venligst mit svar på din egen svar tråd.
Underbyg venligst hvorfor det ikke skulle være sikkert fordi det foregår i
javascript?
Birger Sørensen
Nu har jeg aldrig gjort noget sådant selv - fordi jeg mener det ikke er
sikkert.
Første spørgsmål er, hvad gør de mennesker der slår js fra?
Den anden betragtning er, hvordan js bærer sig ad med at kryptere AES,
uden at kende encryption koden?
Hvis den står js - altså det der sendes til browseren, eller i
returkoden fra browser til server - kan den fanges af dem der vil.
Dermed kan de også decryptere retur værdier - og altså få fingre i de
passwords du påstår er sikre.
Hvis du nu brugte MD5, der ikke kan decrypteres, ville jeg måske være
mindre skeptisk.
Men du har stadig et problem. Selv hvis dit password til din database
er sikkert, skal du have data den anden vej, og det er så nødt til at
være i klartekst, hvis dine brugere skal kunne bruge det til noget. Og
her kan du ikke bruge MD5.
Benny Nissen
> >>
Det vil ganske simpelt ikke virke hvis man slår javascript fra. Det er et krav
at javascript er slået til for at det virker.
AES algoritmen er ganske simpelt implementeret i javascript. Alt der sendes ud
på nettet er uforståeligt binær kode (passwords). Dette gælder begge veje.
Således er alt der lagres på serveren ligeledes krypteret. Det bliver først
dekrypteret igen i browseren.
Det er ikke nemt at få fat på master password da det aldrig forlader browseren.
Man skal i hvertfald gøre sig store anstrengelser. Men hvis man kan modificere
javascript som sendes til en bruger kan man få fat på det (men det er ikke helt
nemt). Ligeledes kan der jo installeres en key logger på ens PC, men denne
svaghed gælder jo alle systemer der beskyttes af et password.
Følgende javascript filer inkluderes i header. Du kan sætte pcrypt.dk foran
stien for at kikke på kildekoden.
<script type='text/javascript' src='js/jquery/jquery.js'></script>
<script type='text/javascript' src='js/jquery/jquery.alerts.js'></script>
<script type='text/javascript' src='js/jquery/jquery.cluetip.js'></script>
<script type='text/javascript' src='js/json2.js'></script>
<script type='text/javascript' src='js/aes.js'></script>
<script type='text/javascript' src='js/sha256.js'></script>
<script type='text/javascript' src='js/lz77.js'></script>
<script type='text/javascript' src='js/dateformat.js'></script>
<script type='text/javascript' src='js/ucsv.js'></script>
<script type='text/javascript' src='js/php.js'></script>
<script type='text/javascript' src='js/pcrypt.js'></script>
<script type='text/javascript' src='js/passwordcrypt.js'></script>
Birger Sørensen
AES kræver så vidt jeg ved en key af en art. Den kan i sagens natur
ikke sendes krypteret - hverken den ene eller den anden vej.
Men jeg skal da ikke være påståelig. Måske er dit system "sikkert nok".
Personligt vil jeg alrdrig lægge mine passwords et sted hvor de ville
kunne findes af andre - med organiseret overlæg eller tilfældigt.
Benny Nissen
Det mest interresante står nok i denne fil: http://pcrypt.dk/js/pcrypt.js
Benny Nissen
> AES kræver så vidt jeg ved en key af en art. Den kan i sagens natur
> ikke sendes krypteret - hverken den ene eller den anden vej.
Key (master password) sendes heller aldrig nogen steder. Den forbliver altid i
browseren. Faktisk kun i den side/tab som er åben. Kryptering og dekryptering
foregår jo også kun i browseren (js) så der er ikke behov for at den sendes andre
steder hen.
> Men jeg skal da ikke være påståelig. Måske er dit system "sikkert nok".
> Personligt vil jeg alrdrig lægge mine passwords et sted hvor de ville
> kunne findes af andre - med organiseret overlæg eller tilfældigt.
>
Jeg ved det er denne holdnig jeg er oppe imod ;-)
Dine passwords kan ikke findes af andre hverken med organiseret overlæg eller
tilfældigt. Selvfølgelig under forudsætning af at jeg ikke har lavet en virkelig
alvorlig sikkerhedsfejl i implementeringen, men dette gælder alt der skal være
sikkert.
Tror ikke det er mere sikkert at ligge krypterede data på din egen pc end på en
server. De kan ikke anvendes til noget begge steder. Det er andre steder man
ville angribe sikkerheden!
John
>
>Fik en grafikker til at lave det overordnede design og logo.
>
Syntes nu nok at designet halter, grafiker eller ej.
Designet giver flashback til tidlig halvfemserne.
Kedeligt uden liv, ikke engang en ordentlig menu.
ps ville heller ikke overlade mine passwords til fremmede ;-)
--
Mvh John
www.wordpresstema.dk
www.wordpress.dk/forum
Benny Nissen
> Den 28-05-2011, skrev Benny Nissen:
>
> >
> >Fik en grafikker til at lave det overordnede design og logo.
> >
> Syntes nu nok at designet halter, grafiker eller ej.
>
> Designet giver flashback til tidlig halvfemserne.
>
> Kedeligt uden liv, ikke engang en ordentlig menu.
>
> ps ville heller ikke overlade mine passwords til fremmede ;-)
>
Måske minder det om tidligere designs, men vil ikke lave
grundlæggende ændringer på nuværende tidspunkt. Kun mindre
ændringer!
Men tak for feedback :-)
Birger Sørensen
> Birger Sørensen wrote in dk.edb.internet.webdesign.ris+ros:
>
>> AES kræver så vidt jeg ved en key af en art. Den kan i sagens natur
>> ikke sendes krypteret - hverken den ene eller den anden vej.
>
> Key (master password) sendes heller aldrig nogen steder. Den forbliver altid
> i browseren. Faktisk kun i den side/tab som er åben. Kryptering og
> dekryptering foregår jo også kun i browseren (js) så der er ikke behov for at
> den sendes andre steder hen.
Så når browseren sender krypterede data til serveren, gætter den sig
til key'en?
Eller js'en gætter key'en for at kunne dekryptere data fra serveren?
>> Men jeg skal da ikke være påståelig. Måske er dit system "sikkert nok".
>> Personligt vil jeg alrdrig lægge mine passwords et sted hvor de ville
>> kunne findes af andre - med organiseret overlæg eller tilfældigt.
>>
>
> Jeg ved det er denne holdnig jeg er oppe imod ;-)
Tough one! :/
> Dine passwords kan ikke findes af andre hverken med organiseret overlæg eller
> tilfældigt. Selvfølgelig under forudsætning af at jeg ikke har lavet en
> virkelig alvorlig sikkerhedsfejl i implementeringen, men dette gælder alt der
> skal være sikkert.
Det er ikke din programmering jeg tvivler. Det ser fornuftigt ud - uden
at jeg har gået i nogen som helst detallier!
Der er mere det principielle.
> Tror ikke det er mere sikkert at ligge krypterede data på din egen pc end på
> en server. De kan ikke anvendes til noget begge steder. Det er andre steder
> man ville angribe sikkerheden!
Som f.eks. en database, der indholder mange menneskers passwords til
mange forskellige steder?
Og her hos mig selv, er jeg selv herre. En effektiv virusbekyttelse, en
fornuftig firewall, og der er ikke nogen der kommer til dem. Så er jeg
også fri for at kryptere dem.
Ulempen selvfølgelig, at jeg skal være her, for at kunne se dem.
Men det er nu heller ikke sådan jeg gør. :-)
Din idé er da fin. Men måske skal clientside være en applikation i
stedet for en webside. Så kan man have den med sig på en dongle (eller
en af de andre moderne ting, der kan det der med 'nettet).
Benny Nissen
> Benny Nissen frembragte:
> > Birger Sørensen wrote in dk.edb.internet.webdesign.ris+ros:
> >
> >> AES kræver så vidt jeg ved en key af en art. Den kan i sagens natur
> >> ikke sendes krypteret - hverken den ene eller den anden vej.
> >
> > Key (master password) sendes heller aldrig nogen steder. Den forbliver altid
> > i browseren. Faktisk kun i den side/tab som er åben. Kryptering og
> > dekryptering foregår jo også kun i browseren (js) så der er ikke behov for at
> > den sendes andre steder hen.
>
> Så når browseren sender krypterede data til serveren, gætter den sig
> til key'en?
> Eller js'en gætter key'en for at kunne dekryptere data fra serveren?
Du indtaster AES key (master password) når du logger på systemet (brugernavn og
adgangskode). Det er lidt teknisk, men brugernavn krypteres af adgangskoden
(master password) og anvendes som unik nøgle til server databasen (identifiserer
bruger og dennes data).
Når nu noget skal krypteres og sendes til databasen (alt sker i javascript) laver
jeg en SHA256 værdi af adgangskoden og en salt (kommer fra server og oprettes når
bruger oprettes - så for at kende AES key skal man have noget fra både client og
server siden). Denne SHA256 AES key anvendes så til at kryptere data i browser som
så sendes til server (krypteret).
Når man skal hente noget fra server er det faktisk bare den omvendte process. De
krypterede data hentes fra server til klienten og AES key dekryptere data der.
>
> >> Men jeg skal da ikke være påståelig. Måske er dit system "sikkert nok".
> >> Personligt vil jeg alrdrig lægge mine passwords et sted hvor de ville
> >> kunne findes af andre - med organiseret overlæg eller tilfældigt.
> >>
> >
> > Jeg ved det er denne holdnig jeg er oppe imod ;-)
>
> Tough one! :/
>
> > Dine passwords kan ikke findes af andre hverken med organiseret overlæg eller
> > tilfældigt. Selvfølgelig under forudsætning af at jeg ikke har lavet en
> > virkelig alvorlig sikkerhedsfejl i implementeringen, men dette gælder alt der
> > skal være sikkert.
>
> Det er ikke din programmering jeg tvivler. Det ser fornuftigt ud - uden
> at jeg har gået i nogen som helst detallier!
> Der er mere det principielle.
>
> > Tror ikke det er mere sikkert at ligge krypterede data på din egen pc end på
> > en server. De kan ikke anvendes til noget begge steder. Det er andre steder
> > man ville angribe sikkerheden!
>
> Som f.eks. en database, der indholder mange menneskers passwords til
> mange forskellige steder?
Kan ikke bruges til noget da passwords er krypteret med forskellige AES keys (en
for hver bruger af systemet). Det er virkelig bare tilfældige binære strenge med
mindre man kender AES key som er unik pr bruger og dermed dennes data.
>
> Og her hos mig selv, er jeg selv herre. En effektiv virusbekyttelse, en
> fornuftig firewall, og der er ikke nogen der kommer til dem. Så er jeg
> også fri for at kryptere dem.
> Ulempen selvfølgelig, at jeg skal være her, for at kunne se dem.
> Men det er nu heller ikke sådan jeg gør. :-)
Så hvem som helst der opnår adgang til din PC kan altså se dine adgangskoder -
tror ikke det er mere sikkert ;-)
Ligeledes har du ikke adgang til dem fra andre steder end din egen PC.
>
> Din idé er da fin. Men måske skal clientside være en applikation i
> stedet for en webside. Så kan man have den med sig på en dongle (eller
> en af de andre moderne ting, der kan det der med 'nettet).
>
Arbejder på en javascript app til Iphone og Android der har adgang til de samme
data. En applikation vil være begrænset til et bestemt operativsystem og du skulle
slæbe den rundt med dig :-) Det er derfor man har web browsere for at undgå den
slags problemer.
Benny Nissen
Og denne funktion der kryptere data og sender det til server:
function setdata(session, cryptkey, saltcrypt, dataname, data, id, callback)
{
try
{
var datastring = JSON.stringify(data);
lz = new LZ77();
setvalue(dataname, datastring);
datastring = lz.compress(datastring);
datastring = encryptstring(cryptkey, saltcrypt, datastring);
jsonrpc('setdata', session, dataname, [datastring, crc32(datastring)], id,
callback);
return true;
}
catch(e)
{
return false;
}
}
Først laver vi et array om til en tekststreng vha. JSON
Så gemmes denne tekststreng lokalt i browseren (tab/vindue) med setvalue (hurtigere
adgang så det ikke skal hentes fra serveren hver gang)
Derefter komprimeres tekststrengen med LZ algoritmen (spare på båndbredde og
lagerplads)
Så krypteres data med funktionen encryptstring.
Til slut sendes data til server med jsonrpc funktionen (og der laves en crc32 på
data for at sikre at de ankommer intakt). jsonrpc står for JSON Remote Procedure
Call og er en standard for kommunikation mellem browser og server v.h.a. ajax
Benny
Allan Vebel
>> Personligt vil jeg alrdrig lægge mine passwords
>> et sted hvor de ville kunne findes af andre - med
>> organiseret overlæg eller tilfældigt.
>
> Jeg ved det er denne holdnig jeg er oppe imod ;-)
Jeg er af samme mening som Birger. Det kan da
godt være at det er smart og sikkert, men jeg stoler
mere på en lokal løsning der ikke involverer at den
slags skal sendes over nettet.
> under forudsætning af at jeg ikke har lavet en
> virkelig alvorlig sikkerhedsfejl
Det er jo netop den slags brugeren ikke ved. Du
er altså oppe mod en yderst skeptisk brugerskare,
hvordan vil du angribe sådag en sag, sådan rent
markedsføringsmæssigt?
Jeg har altid alle adgangskoder med på en usb-pen,
så kan jeg bruge dem verden over;o)
--
Allan Vebel
http://vebel.dk | http://html-faq.dk
Benny Nissen
> Benny Nissen skrev:
>
> >> Personligt vil jeg alrdrig lægge mine passwords
> >> et sted hvor de ville kunne findes af andre - med
> >> organiseret overlæg eller tilfældigt.
> >
> > Jeg ved det er denne holdnig jeg er oppe imod ;-)
>
> Jeg er af samme mening som Birger. Det kan da
> godt være at det er smart og sikkert, men jeg stoler
> mere på en lokal løsning der ikke involverer at den
> slags skal sendes over nettet.
ikke så vigtige passwords i dette system og beholde de vigtigste
på en USB nøgle.
Men har stadig holdningen at de andre løsninger der er blevet
fremsat her, ikke er mere sikker !!
> > under forudsætning af at jeg ikke har lavet en
> > virkelig alvorlig sikkerhedsfejl
>
> Det er jo netop den slags brugeren ikke ved. Du
> er altså oppe mod en yderst skeptisk brugerskare,
> hvordan vil du angribe sådag en sag, sådan rent
> markedsføringsmæssigt?
Ved ikke hvordan det skal angribes markedsføringsmæssigt. Det er
et tilbud og ikke noget jeg nødvendigvis skal tjene penge på - så
tiden må arbejde for det eller imod det!
Man kommer aldrig ud over det problem at der kan være lavet en
sikkerhedsfejl. Dette gælder også stand-alone-løsninger. Jeg
siger bare at her minder det lidt om en stand-alone-løsning fordi
det kører alene på klient siden og server anvendes kun til
lagring af krypterede data.
Altså lidt samme løsning som hvis man lavet et specielt windows
program der krypterede ens data og lagrede det på en central
server. Sådanne løsninger findes der mange af og de bliver
anvendt. Folk siger bare straks "ikke sikkert" når det køre i en
browser.
Her vil jeg faktisk mene at sikkerheden er bedre idet alle har
adgang til kildekoden og kan kontrollere den.
> Jeg har altid alle adgangskoder med på en usb-pen,
> så kan jeg bruge dem verden over;o)
>
Fin løsning, men en masse mennesker kan ikke finde ud af det
ellers simple system og anvender meget usikre passwords eller
lign.
Henrik Eriksen
ulyst til at opbevare koder på nettet (blandt andet fra mig).
Men efter at have tænkt lidt over det, synes jeg egentlig ikke konceptet er
så dårligt igen.
Det er rigtigt at jeg selv (og mange andre) opbevarer koder i
tekstdokumenter på PC og mobil, men jeg gør det ikke "direkte".
Når jeg noterer koder ned, bruger jeg altid et "pseudo-kode" system, som er
temmelig indforstået. Man kan med andre ord ikke læse mine koder direkte, de
skal "oversættes". Og det kan kun jeg.
Netop fordi en der hugger min PC ikke uden videre skal kunne tømme min
netbank - det ville ærgre mig at miste alle mine penge, man ved aldrig
hvornår jeg får brug for alle 42,50 på en gang ;-)
Om så mine koder ligger på min PC eller på nettet burde være ligemeget.
Desværre betyder "ligemeget" her, at jeg dermed lige så godt kan fortsætte
med at opbevare det i min mobiltelefon. Den har jeg alligevel med mig altid,
og det er endnu nemmere end en web-løsning.
Jeg synes stadigvæk siden er flot lavet, uden alt mulig fest og farver.
Men du skulle stadig få flyttet hængelåsen. Jeg forstår godt din
tilbagemelding, men så burde den stå istedet for "C" i "CRYPT" og
spejlvendes vandret.
Den kan godt minde lidt om et "C", specielt hvis lås-delen bliver gjort
mindre.
Benny Nissen
> ulyst til at opbevare koder på nettet (blandt andet fra mig).
>
> Men efter at have tænkt lidt over det, synes jeg egentlig ikke konceptet er
> så dårligt igen.
Tak for dette, var ved at blive lidt nedtrykt over tilbagemeldingerne. På den
anden side tror jeg ikke at dem der læser denne gruppe er den typiske
målgruppe - så der er stadig håb
>
> Det er rigtigt at jeg selv (og mange andre) opbevarer koder i
> tekstdokumenter på PC og mobil, men jeg gør det ikke "direkte".
> Når jeg noterer koder ned, bruger jeg altid et "pseudo-kode" system, som er
> temmelig indforstået. Man kan med andre ord ikke læse mine koder direkte, de
> skal "oversættes". Og det kan kun jeg.
> Netop fordi en der hugger min PC ikke uden videre skal kunne tømme min
> netbank - det ville ærgre mig at miste alle mine penge, man ved aldrig
> hvornår jeg får brug for alle 42,50 på en gang ;-)
>
> Om så mine koder ligger på min PC eller på nettet burde være ligemeget.
> Desværre betyder "ligemeget" her, at jeg dermed lige så godt kan fortsætte
> med at opbevare det i min mobiltelefon. Den har jeg alligevel med mig altid,
> og det er endnu nemmere end en web-løsning.
>
> Jeg synes stadigvæk siden er flot lavet, uden alt mulig fest og farver.
>
> Men du skulle stadig få flyttet hængelåsen. Jeg forstår godt din
> tilbagemelding, men så burde den stå istedet for "C" i "CRYPT" og
> spejlvendes vandret.
> Den kan godt minde lidt om et "C", specielt hvis lås-delen bliver gjort
> mindre.
Vil kikke lidt på det logo og se om det ikke kan forbedres!
Har nu lavet respons ved hoover på links som tidligere foreslået.
Stig Johansen
> Det mest interresante står nok i denne fil: http://pcrypt.dk/js/pcrypt.js
Ja, og her benytter man sessionstorage, så man skal være S*TANS sikker på
sikring mod XSS angreb.
'Sikkerheden' (eller mangel på samme) er decimeret til 'programmørens' evne
til at sikre de mest simple 'javascript attack', og ikke kun dekryptering.
Det er en 'ommer'.
(Og lad være med at tro der nogensinde kan findes sikre løsninger, der er
baseret på javascript) - spild af tid.
--
Med venlig hilsen
Stig Johansen
Benny Nissen
> Benny Nissen wrote:
>
> > Det mest interresante st�r nok i denne fil: http://pcrypt.dk/js/pcrypt.js
>
> Ja, og her benytter man sessionstorage, s� man skal v�re S*TANS sikker p�
> sikring mod XSS angreb.
>
> 'Sikkerheden' (eller mangel p� samme) er decimeret til 'programm�rens' evne
>
> Det er en 'ommer'.
>
> baseret p� javascript) - spild af tid.
> --
> Med venlig hilsen
> Stig Johansen
Man kommer aldrig ud over at den der har implementeret et system kan have
lavet en fejl der giver mulighed for andre at f� adgang til noget de ikke
skulle have haft adgang til. Derfor at dette bl.a. er Open Source.
Kan nu ikke se at det at jeg gemmer noget i sessionstorage skulle g�re det
mere f�lsomt for et XSS. Det skal jo p� et tidspunkt vises p� sk�rmen og s�
vil det altid kunne "fanges" af ondsindet javascript.
Jeg har virkelig fors�gt at hindre XSS angreb bedst muligt. Hvis man gemte p�
en alm. PC ville man jo ogs� kunne komme ud for en keylogger eller en form for
virus der kunne f� adgang til ens data. Men i dette tilf�lde ville der da v�re
en hvis form for beskyttelse i at man ikke helt nemt kan f� adgang til den
bin�re maskinkode for programmet, Ligeledes er det ikke helt nemt at f� fat p�
Javascript til dette system. Men der er en risiko selvf�lgelig og der er m�ske
st�rre chance for at en vil rette sit angreb mod en online l�sning.
Der findes overordnet 2 former for XSS angreb Non-persistent og Persistent.
Den f�rste mulighed f�r kun adgang til en enkelt brugers data og den anden f�r
permanent placeret noget kode som i teorien kan give adgang til alle brugers
data. Jeg har fors�gt at beskytte mig mod begge muligheder og alle kan kikke
mig over skulderen som du ligeledes har gjort!
Mvh
Benny
--
Vil du l�re at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- P�dagogiske tutorials p� dansk
Benny Nissen
> > Benny Nissen wrote:
> >
> > Ja, og her benytter man sessionstorage, så man skal være S*TANS sikker på
> >
> > 'Sikkerheden' (eller mangel på samme) er decimeret til 'programmørens' evne
> >
> > Det er en 'ommer'.
> >
> > --
> > Med venlig hilsen
> > Stig Johansen
>
> Man kommer aldrig ud over at den der har implementeret et system kan have
>
> mere følsomt for et XSS. Det skal jo på et tidspunkt vises på skærmen og så
>
The localStorage JavaScript object is functionally identical to the
sessionStorage object. They only differ in persistence and scope. Scope:
localStorage data is accessible across all browser windows while sessionStorage
data is confined to the browser window that it was created in.
The data you store is automatically associated with the domain under which the
script is running. This means strictly we will disallow XSS which is very
important.
Read more: http://geeknizer.com/html-5-client-storage/#ixzz1PbStcqH7
--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
Stig Johansen
> Benny Nissen wrote in dk.edb.internet.webdesign.ris+ros:
>> Stig Johansen wrote in dk.edb.internet.webdesign.ris+ros:
>> > Det er en 'ommer'.
>> >
>> > (Og lad v�re med at tro der nogensinde kan findes sikre l�sninger, der
>> > er baseret p� javascript) - spild af tid.
>> >
>> > --
>> > Med venlig hilsen
>> > Stig Johansen
>>
>> Man kommer aldrig ud over at den der har implementeret et system kan have
>> lavet en fejl der giver mulighed for andre at f� adgang til noget de ikke
>> skulle have haft adgang til. Derfor at dette bl.a. er Open Source.
>>
>> Kan nu ikke se at det at jeg gemmer noget i sessionstorage skulle g�re
>> det mere f�lsomt for et XSS. Det skal jo p� et tidspunkt vises p� sk�rmen
>> og s� vil det altid kunne "fanges" af ondsindet javascript.
>>
>
> The localStorage JavaScript object is functionally identical to the
> sessionStorage object. They only differ in persistence and scope. Scope:
> localStorage data is accessible across all browser windows while
> sessionStorage data is confined to the browser window that it was created
> in.
>
> The data you store is automatically associated with the domain under which
> the script is running. This means strictly we will disallow XSS which is
> very important.
Beklager hvis jeg er lidt h�rd, men jeg har bla. arbejdet med sikkerhed
inden for bank/vekselerer/finansiering siden vi (DK) var verdens f�rste
nation med 'papirl�se obligationer' (driftstart p�sken '83).
Det er klart man skal skelne mellem statshemmeligheder, eller
'berigelsesaspektet'[1] eller Tante 'Odas breve', s� afh�ngig af hvilken
sikringsgrad man �nsker kan din l�sning muligvis v�re OK.
[1] I forhold til v�rdipapirer snakkede vi en oms�tning p� > 1 mia kr/DAG,
hvilket bragte berigelsesaspektet *s�rdeles* h�jt.