---
# System prepended metadata

title: ARS - 3
tags: [C&C, ' ARS', ' moemoea.fierin']

---

---
title: ARS - 3
tags: C&C, moemoea.fierin, ARS
author: Moemoea Fiérin
---

# <span style='color:red'>Informations Générales</span>
Faire la certification rapidement.
Les dates d'exposé et de DM sont en ligne.
DEFNET Annulé


# <span style='color:red'>Authentification</span>
Il existe 3 types d'authentification:
- ce que je connais (mdp)
- ce que je posède (badge)
- ce que suis (biometrie)

Ces 3 facteurs peuvent se combiner: c'est ce qu'on appèle de **authentification forte**.
:::danger
Une authentification fort **n'est pas** un mot de passe fort :warning: 
:::

## OTP
**OTP**: (One Time Password) c'est un mdp a usage unique.
*Exemple: Google Authentificator.*

Ces OTP sont générés de deux manières:
- ++synchrone++: le service fait une derivation du mdp initial, si les deux matchs on peut rentrer.
- ++asynchrone++: le server envoie un element de donnée qui va nous permettre de generer le mdp et on va lui renvoyer le mdp unique

# <span style='color:red'>Définir authentification centralisée / fédérative / coopérative</span>
- Challenges & Difficultés ?

## Problématique de ces mdp:
**Négligence**: on peut les laisser trainer dans plein d'endroits. (dans des fichiers non sécurisé, sur github, ...)

**Autres possibilités:** 
- qqn nous ciblé: bruteforce, dictionnaire
    - attck sur algorithme de crypto (par ce qu'ils ont mal été dev)
    - qualité de l'algo
    - qualité de l'aléa
    - jouer sur l'écosysteme dans lequel l'algo tourne
- outils
    - sites en ligne exposant les comptes
    - ...

## Authentification centralisé
Utilisateur n'a pas bcp de moyen de s'authentifier : (exemple) Active Directory sur Windows.

Augmente notre risque systemique et en meme temps, on simplifie la gestion (150 comptes utilisateur => la securite du plus faible fera craque les autres)

## Authentification fédérative
Utiliser une application sécurisé pour se connecter. Cette appli n'aura rien a voir avec l'appli sur laquelle je me connecte.

Exemple: une appli random qui propose de se co avec Google.

## Authentification coopérative

# <span style='color:red'>Définir : SSO, SLO, CSO</span>
## SSO
**SSO:** Single Sign ON

## SLO
**SLO:** Single Log Out ???

## CSO

# <span style='color:red'>Savoir expliquer la différence entre un annuaire et une base de données pour l’authentification?</span>


# <span style='color:red'>Savoir expliquer SAML, WS-Federation, OpenID et les principes de la délégation de l'authentification (Oauth, BBAuth, AuthSub, Facebook Auth, Windows Live ID...)</span>
# <span style='color:red'>Quels sont les challenges pour les états sur l’identité numérique ?</span>
# <span style='color:red'>Savoir expliquer les principes de PAM / WINLOGON</span>
# <span style='color:red'></span>

# Kerberos

# Modele Mitre ATTCK
recense toutes les techniques. C'est une bases de données: un referentiels pour le FIC [Mitre Att&ck](https://attack.mitre.org/tactics/pre/)

# Security by design
Par defaut, on intègre la sécurité en pensant correctement l'applicatif.
Si je ne peux pas tracé l'attaquant => pas tres secure by design 

Voire de technique d'anonymasation des données: garder une cles de correspondance qui me peremyyra de faire le suivi plus tard.

Plus en + de controle d'acces. il vont limiter l'impact (protection de donnée pour proteger la vie privé de l'utilisatueur)

Security by default.