Varsel om svindel på Hilton Tokyo
- Thread starter krølle
- Start date
Re: Varsel om svindel på Hilton Tokyo
Ja, nei si det. Jeg fant den på AirlineEmployeeRouting gruppen, men kjenner ikke fyren, og profilen er ganske tom, så hvem vet.
Ja, nei si det. Jeg fant den på AirlineEmployeeRouting gruppen, men kjenner ikke fyren, og profilen er ganske tom, så hvem vet.
KristianSk
Joker
Re: Varsel om svindel på Hilton Tokyo
Noen tips til en VPN løsning for oss som ikke har dette fra arbeidsgiver?
Noen tips til en VPN løsning for oss som ikke har dette fra arbeidsgiver?
Re: Varsel om svindel på Hilton Tokyo
https://www.expressvpn.com/
Fungerer veldig bra, for eksempel i Kina, hvor mye er sperret. App til alt, og lett å sette opp.
Du kan selv velge serverlokasjon.
https://www.expressvpn.com/
Fungerer veldig bra, for eksempel i Kina, hvor mye er sperret. App til alt, og lett å sette opp.
Du kan selv velge serverlokasjon.
Re: Varsel om svindel på Hilton Tokyo
Så godt som alle banker bruker to-faktorautentisering, dvs. en kombinasjon av noe du vet (passordet) og noe du har (kodebrikke/mobil). Dette er veldig sikkert. Noen banker som f.eks. Skandiabanken sender imidlertid ut en engangskode på SMS i stedet for å bruke kodebrikke. SMS-meldinger er ikke kryptert og går gjennom luft, og er teoretisk sett enkle å fange opp for en tredjepart. Bruker du en bank som har engangskode på SMS, kombinert med at du har samme passordet "alle steder" og sitter på et åpent trådløst nettverk, så er altså andres vei inn i din nettbank relativt kort.
Så godt som alle banker bruker to-faktorautentisering, dvs. en kombinasjon av noe du vet (passordet) og noe du har (kodebrikke/mobil). Dette er veldig sikkert. Noen banker som f.eks. Skandiabanken sender imidlertid ut en engangskode på SMS i stedet for å bruke kodebrikke. SMS-meldinger er ikke kryptert og går gjennom luft, og er teoretisk sett enkle å fange opp for en tredjepart. Bruker du en bank som har engangskode på SMS, kombinert med at du har samme passordet "alle steder" og sitter på et åpent trådløst nettverk, så er altså andres vei inn i din nettbank relativt kort.
Re: Varsel om svindel på Hilton Tokyo
... Og du er logget på via en IMSI-catcher eller noen opererer en 3GPP-protokoll-logger i den cellen ...
Fortsatt sånn relativt trygt hvis man ikke ligger på statspolizei-nivå.
Men poenget er uansett at å gjenbruke enkle passord på mange sites er fy-fy. Det er ikke spesielt dyrt eller komplisert å bruke en passord-app som for eksempel LastPass, så får man litt mer ro i sjelen når slike innbrudd blir oppdaget. Og ikke minst når de IKKE blir oppdaget
... Og du er logget på via en IMSI-catcher eller noen opererer en 3GPP-protokoll-logger i den cellen ...
Fortsatt sånn relativt trygt hvis man ikke ligger på statspolizei-nivå.
Men poenget er uansett at å gjenbruke enkle passord på mange sites er fy-fy. Det er ikke spesielt dyrt eller komplisert å bruke en passord-app som for eksempel LastPass, så får man litt mer ro i sjelen når slike innbrudd blir oppdaget. Og ikke minst når de IKKE blir oppdaget
Re: Varsel om svindel på Hilton Tokyo
Ingen problem å knekke HTTPS eller SSL med man in the middle angrep.
Finnes faktsik sikkerhetsbokser som gjør dette for å sjekke at du egentlig gjør på et nettverk
Ingen problem å knekke HTTPS eller SSL med man in the middle angrep.
Finnes faktsik sikkerhetsbokser som gjør dette for å sjekke at du egentlig gjør på et nettverk
Re: Varsel om svindel på Hilton Tokyo
Dette var interessant og nytt for meg. Har du noe mer info om dette ?
Jeg fant nedenfor info ang dette, tar gjerne imot andre linker som forklarer evt hvordan dette er mulig.
stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding
Man-in-the-middle attacks on SSL are really only possible if one of SSL's preconditions is broken, here are some examples;
The server key has been stolen - means the attacker can appear to be the server, and there is no way for the client to know.
The client trusts an untrustworthy CA (or one that has had it's root key stolen) - whoever holds a trusted CA key can generate a certificate pretending to be the server and the client will trust it. With the number of CAs pre-existing in browsers today, this may be a real problem. This means that the server certificate would appear to change to another valid one, which is something most clients will hide from you.
The client doesn't bother to validate the certificate correctly against its list of trusted CA's - anyone can create a CA. With no validation, "Ben's Cars and Certificates" will appear to be just as valid as Verisign.
The client has been attacked and a fake CA has been injected in his trusted root authorities - allows the attacker to generate any cert he likes, and the client will trust it. Malware tends to do this to for example redirect you to fake banking sites.
Especially #2 is rather nasty, even if you pay for a highly trusted certificate, your site will not be in any way locked to that certificate, you have to trust all CAs in the client's browser since any of them can generate a fake cert for your site that is just as valid. It also does not require access to either the server or the client.
Ingen problem å knekke HTTPS eller SSL med man in the middle angrep.
Finnes faktsik sikkerhetsbokser som gjør dette for å sjekke at du egentlig gjør på et nettverk
Dette var interessant og nytt for meg. Har du noe mer info om dette ?
Jeg fant nedenfor info ang dette, tar gjerne imot andre linker som forklarer evt hvordan dette er mulig.
stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding
Man-in-the-middle attacks on SSL are really only possible if one of SSL's preconditions is broken, here are some examples;
The server key has been stolen - means the attacker can appear to be the server, and there is no way for the client to know.
The client trusts an untrustworthy CA (or one that has had it's root key stolen) - whoever holds a trusted CA key can generate a certificate pretending to be the server and the client will trust it. With the number of CAs pre-existing in browsers today, this may be a real problem. This means that the server certificate would appear to change to another valid one, which is something most clients will hide from you.
The client doesn't bother to validate the certificate correctly against its list of trusted CA's - anyone can create a CA. With no validation, "Ben's Cars and Certificates" will appear to be just as valid as Verisign.
The client has been attacked and a fake CA has been injected in his trusted root authorities - allows the attacker to generate any cert he likes, and the client will trust it. Malware tends to do this to for example redirect you to fake banking sites.
Especially #2 is rather nasty, even if you pay for a highly trusted certificate, your site will not be in any way locked to that certificate, you have to trust all CAs in the client's browser since any of them can generate a fake cert for your site that is just as valid. It also does not require access to either the server or the client.
Re: Varsel om svindel på Hilton Tokyo
Dette må du nesten forklare nærmere.
Jeg er rimelig godt kjent med hvordan TLS (HTTPS) fungerer og er implementert i ulike browsere. Selv om det finnes praktiske angrep mot SHA-1, vil jeg på ingen måte kalle dem enkle eller "ingen problem", i tillegg til å at det i praksis er faset ut. Hvilke andre angrepsvektorer er det du tenker på som "ingen problem"?
Utstyr som gjør rutinemessig "man in the middle" krever at du installerer egne sertifikater for å la deg avlytte. Det kan bli gjort i forbindelse med brannvegginstallasjoner i en del bedrifter, overvåkingssystemer for foreldrekontroll o.l., men er langt fra vanlig.
Ingen problem å knekke HTTPS eller SSL med man in the middle angrep.
Finnes faktsik sikkerhetsbokser som gjør dette for å sjekke at du egentlig gjør på et nettverk
Dette må du nesten forklare nærmere.
Jeg er rimelig godt kjent med hvordan TLS (HTTPS) fungerer og er implementert i ulike browsere. Selv om det finnes praktiske angrep mot SHA-1, vil jeg på ingen måte kalle dem enkle eller "ingen problem", i tillegg til å at det i praksis er faset ut. Hvilke andre angrepsvektorer er det du tenker på som "ingen problem"?
Utstyr som gjør rutinemessig "man in the middle" krever at du installerer egne sertifikater for å la deg avlytte. Det kan bli gjort i forbindelse med brannvegginstallasjoner i en del bedrifter, overvåkingssystemer for foreldrekontroll o.l., men er langt fra vanlig.
Re: Varsel om svindel på Hilton Tokyo
Et annet eksempel er sas.no, der selve login-informasjon blir sendt kryptert, men selve loginsiden er ikke kryptert så den kan være manipulert.
Men til tidligere poster lenger opp - husk at dette høyst sannsynlig ikke var snakk om en norsk bank. Det finnes mange banker på nett som ikke har alt på stell
Eller det at folk får opp en advarsel om feil med sertifikat, og "mannen i gata" trykker jo bare "fortsett" som vanlig på alle feilmeldinger. Jeg har også sett live eksempler der man har lurt folk med falske nett, og satt opp falsk loginside.
Et annet eksempel er sas.no, der selve login-informasjon blir sendt kryptert, men selve loginsiden er ikke kryptert så den kan være manipulert.
Men til tidligere poster lenger opp - husk at dette høyst sannsynlig ikke var snakk om en norsk bank. Det finnes mange banker på nett som ikke har alt på stell
Superhai
ScanFlyer Rusty
Re: Varsel om svindel på Hilton Tokyo
Det er noen åpne wifi-nett, som bruker falske sertifikater for å fange opp at man prøver å logge seg på disse. Hensikten er selvfølgelig at man skal få innloggingssiden som ikke kommer om man går rett på en kryptert side i mange slike løsninger. Men her mener jeg at hensikten ikke helliger middelet. F.eks. på OSL sitt åpne nett, så må man som regel inn på en http-side, og ikke https for å få opp innloggingssiden, siden de ikke har slik måte å løse problemet.
Det er noen åpne wifi-nett, som bruker falske sertifikater for å fange opp at man prøver å logge seg på disse. Hensikten er selvfølgelig at man skal få innloggingssiden som ikke kommer om man går rett på en kryptert side i mange slike løsninger. Men her mener jeg at hensikten ikke helliger middelet. F.eks. på OSL sitt åpne nett, så må man som regel inn på en http-side, og ikke https for å få opp innloggingssiden, siden de ikke har slik måte å løse problemet.