An overview of authentication and authorisation concepts as well as common pitfalls and security issues. We will start with authentication principles and common practices. Then we will explore security issues with different authentication approaches in applications and more importantly - identify countermeasures for them. After that we will look into core rules regarding implementation of authorisation in applications. Mārtiņš is a senior consultant at Autentica and has extensive experience in software development and IT process design. He holds CISSP, CISM and CPTE certificates in computer security domain.

1. Autentifikācija un autorizācija
Mārtiņš Ķemme
SIA Autentica, vecākais konsultants

2. Mārtiņš Ķemme
SIA Autentica, vecākais konsultants
IT procesu konsultants, projektu vadītājs, konsultants
Certified Information Systems Security Professional (ISC)²
Certified Information Security Manager (ISACA)
Certified Penetration Testing Engineer (Mile2)

3. autentifikācija
identitātes pārbaude
autorizācija
tiesību piešķiršana

4. autentifikācija
Ko lietotājs zina?
(PIN, parole)
Kas lietotājam ir/pieder?
(viedkarte, kodu kalkulators)
Kas lietotājs ir?
(biometrija, balss atpazīšana)

5. Divu faktoru autentifikācija

6. autentifikācijas riski
lietotājs netiek autentificēts
lietotājs tiek autentificēts nepareizi

7. uzbrukumi autentifikācijas sistēmām
Man-in-the-middle
Paroļu datubāzes nozagšana offline uzbrukumiem
Sociālā inženierija
Kontu pārskaitīšana
DoS uzbrukums ar paroļu atiestatīšanu / kontu bloķēšanu

8. MitM aizsardzība
šifrēts savienojums - https
(autentiskums, integritāte, konfidencialitāte)
keylogger injection over http
rogue access points
Paroles nekad nesūta uz epastu

9. pat šifrētas paroles zog

10. offline uzbrukumu bīstamība
nav laika ierobežojuma
daudz resursu

11. sociālā inženierija

12. Vai mans konts jau
nav uzlauzts?
https://haveibeenpwned.com/

13. paroles atjaunošana
nepieļaut epasta piespamošanu
ģenerēt unikālus atjaunošanas kodus
nepārtraukt esošu sesiju
īpaša drošība:
Neizpaust informāciju, uz kuru epastu tiks nosūtīta info
Pirms sūtīšana papildus pieprasīt drošības jautājumu
paroles maiņa
pieprasīt esošo paroli

14. aizsardzība pret brute force un minēšanu
Ierobežot pieslēgšanās iespējas pēc IP adreses
(bet uzbrucējiem var būt vairākas IP un legāliem klientiem var būt viena IP)
Ierobežot ātrumu
(eksponenciāli palielināt ilgumu, bet uzbrucēji var dzēst cookies)
Uzdot papildu jautājumus vai captcha
(pēc neveiksmīgiem mēģinājumiem, piem., jautājumi par pēdējām transakcijām)
Ierobežot pēc “pirkstu nospiedumiem”
(apskata pieprasījuma atribūtus (pārlūks, versija)
ierobežot visos kanālos (sitewide)
konta bloķēšana
(automātiska atbloķēšanās)

15. aizsardzība pret kontu pārskaitīšanu
pie konta reģistrēšanas nerādīt, ka tāds konts
jau ir reģistrēts
pie pieslēgšanās nerādīt, kas ievadīts nepareizi

16. autentifikācijas aizsardzība
Ierobežošana pēc pieslēgšanās laika
Papildus autentifkācijas faktors

17. problēmas ar captcha

18. autentifikācijas labā prakse
Reautentifikācija pie kritiskām darbībām
Papildu kontrole

19. sistēmas kontu autentifikācija
Autentifikācija ar sertifikātiem
Neiešūšana kodā
username: <%= ENV['POSTGRES_USERNAME'] %>
password: <%= ENV['POSTGRES_PASSWORD'] %>
Neglabāšana repozitorijā

20. paroļu glabāšana
Nekad plain tekstā
Ja paroli var uzzināt (kaut vai no operatora), tad to sistēmu
nevajag lietot
http://plaintextoffenders.com/
Nelietot vājas jaucējfunkcijas
Base64 nav jaucējfunkcija!
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Lietot salt (un varbūt arī pepper)
Drošības jautājumu atbildes arī hashed

21. paroļu stiprība
paroles vs. frāzes
dzelzsgriezējam pasaule ir jasagriež
Qu1ck8r0wnF0x1
paroļu stiprības pārbaude
neierobežot garumu un sarežģītību
pārbaudīt uz zināmām parolēm
(http://weakpass.com/)
dot padomus lietotājam: eBay reģistrācija

22. paroļu glabāšana (pašiem)
notepad
KeePass / KeePassX
LastPass
1Password

23. autentifikācijas protokoli / veidi
Formu bāzēts (tikai pār TLS)
Basic / Digest
PKI - sertifikāti / viedkartes
OAuth
Kerberos
FIDO UAF/U2F
Secure Remote Password (SRP)
(divpusēja autentifikācija)
Security Assertion Markup Language (SAML)
(autentifikācijas un autorizācijas datu apmaiņas formāts)

24. autentifikācijas pakalpojumu sniedzēji
bankas
facebook
Google
Twitter
draugiem.lv pase
Microsoft Account

25. banku autentifikācijas problēmas
Anna de Butkeviča-Mirska
Klotilde van der Stūla-Vollebeka
Anna Mirska de Butkeviča
Klotilde Vollebeka van der Stūla.

26. lietotāju reģistrācija
epastu lietošana lietotājvārdu vietā
viegli atcerēties, mazāk lauku, bet nevar rādīt publiski
lietotājvārdu
reģistrēto epastu pārbauda...
... nosūtot epastu

27. sesiju uzturēšana

28. sesiju uzturēšana
neizgudrot pašiem sesiju pārvaldību
neglabāt sesijas cepumā ”lasāmus” datus
izvairīties no sesijas fiksācijas
pēc autentifikācijas un atslēgšanās mainīt sesijas
identifikatoru
nepieļaut sesijas identifikatora padošanu saitē
autentifikācijas informāciju nesūtīt GET
pieprasījumos
tie saglabājas žurnālu failos

29. cepumi
Secure Attribute - Whenever a cookie contains sensitive information or is a
session token, then it should always be passed using an encrypted tunnel.
Pārlūks šo cepumu sūtīs tikai pār TLS savienojumu.
HttpOnly Attribute - This attribute should always be set even though not
every browser supports it. This attribute aids in securing the cookie from
being accessed by a client side script, it does not eliminate cross site
scripting risks but does eliminate some exploitation vectors.
Javascript-am šis cepums nav pieejams.

30. cepumi
Domain Attribute - Verify that the domain has not been set too loosely. As
noted above, it should only be set for the server that needs to receive the
cookie. For example if the application resides on server app.mysite.com,
then it should be set to "; domain=app.mysite.com" and NOT ";
domain=.mysite.com" as this would allow other potentially vulnerable
servers to receive the cookie.
Path Attribute - Verify that the path attribute, just as the Domain attribute,
has not been set too loosely. Even if the Domain attribute has been
configured as tight as possible, if the path is set to the root directory "/"
then it can be vulnerable to less secure applications on the same server. For
example, if the application resides at /myapp/, then verify that the cookies
path is set to "; path=/myapp/" and NOT "; path=/".

31. cepumi
Expires Attribute - If this attribute is set to a time in the future verify that
the cookie does not contain any sensitive information. For example, if a
cookie is set to "; expires=Sun, 31-Jul-2016 13:45:29 GMT" and it is
currently July 31st 2014, then the tester should inspect the cookie. If the
cookie is a session token that is stored on the user's hard drive then an
attacker or local user (such as an admin) who has access to this cookie can
access the application by resubmitting this token until the expiration date
passes.

32. clickjacking
Clickjacking example
X-Frame-Options Header Types
DENY, which prevents any domain from framing the content. The "DENY"
setting is recommended unless a specific need has been identified for
framing.
SAMEORIGIN, which only allows the current site to frame the content.
ALLOW-FROM uri, which permits the specified 'uri' to frame this page.
(e.g., ALLOW-FROM http://www.example.com)

33. clickjacking aizsardzība ar js
<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>

34. AUTORIZĀCIJA
Now that I know who you are, let’s see if I will let you do what you
want.

35. autorizācijas principi
lomas
parasti balstītas uz pienākumiem vai amatu
grupas
pieejas tiesības piešķir grupām, nevis individuāli

36. autorizācijas principi
fiziska vai loģiska atrašanās vieta
piemēram, tikai lokāli pieslēdzoties, nevis attālināti
resursa izmantošanas laiks
piemēram, tikai darba laikā
transakcijas tips
piemēram, ja apjoms lielāks par X, tad nepieciešama
vadītāja apstiprinājums

37. noklusētās pieejas tiesības
NĒ!

38. least privilege
(need-to-know)
Šis princips nosaka, ka lietotājiem un
programmatūrai jābūt minimālās
nepieciešamās pieejas tiesības, lai varētu
izpildīt savus pienākumus

39. OWASP par lomām
Its important to consider the Goldilocks
principle when role engineering, in that
defining too few, broad roles (thereby
exposing access to functionality users
don't require) is as bad as too many,
tightly tailored roles (thereby restricting
access to functionality users do require).

40. separation of duties
Princips, kas nosaka, ka nevienai personai
nevar būt piešķirtas pārāk liela vara vai
atbildība. Pienākumi un atbildība jāsadala
starp personām, lai novērstu ētikas
konfliktus vai varas ļaunprātīgu
izmantošanu
Piemēram, dokumentu veido viena persona, bet apstiprina cita

41. dinamiska lomu-bāzēta pieejas kontrole
vienai personai var būt gan ievadītāja,
gan apstiprinātāja lomas, bet reizē tās
nevar tikt pielietotas

42. KOPSAVILKUMS

43. Kas jāvaicā klientam par autentifikāciju
• Kā autentificēt lietotāju? (Active Directory, bankas,
eID, Facebook, MKODS, citas puses)
• Vai būs Single-Sign-On? Protokols?
• Vai nepieciešama divu faktoru autentifikācija?
Kāda?
• Vai būs reģistrēšanās (signup)? Kā bloķēt botus?
• Vai būs paroles atiestatīšana? Kuri papildu kanāli
pieejami?
• Cik rūpīgi bloķēt brute force mēģinājumus? kādi
mēri pieļaujami?

44. Kas jāvaicā klientam par sesijas saglabāšanu
• Vai pieļaut vienlaicīgi vairākas sesijas? Ko darīt, ja ir? (Vai
šķirot, piemēram, pēc useragent, ip adreses)
• Vai nepieciešama sesijas beigšana, aizverot tabu?
• Cik ātri vajag beigt sesiju ar noildzi? Vai atlikušo sesijas
laiku vajag attēlot lietotāja interfeisā?
• Vai brīdināt lietotājus par aizdomīgiem piekļuves
gadījumiem, piemēram, no citām valstīm? Kā tās attēlot?
• Vai ir kādi ierobežojumi kontu un sesiju datu glabāšanai?

45. Kas jārealizē, nevaicājot klientam
• Rūpīgi žurnalēt
• Droši glabāt paroles (salt un varbūt arī pepper)
• Aizsargāt pret kontu pārskaitīšanu

46. Paldies!