Je n'arrive pas à piger si je peux/dois donner le même pot de masse
(heu... mot de passe) pour le FileVault que celui qui gère mon accès
"admin" par exemple (ou autre).
Ou bien doit-il être OBLIGATOIREMENT différent de celui de mon log?
Est-ce important s'il est le même (ce qui m'arrangerait car je n'en
n'aurais qu'un dans ce cas, ce qui est plus simple à gérer tout de
même).
Ou bien cela créerait-il un problème?
Merci d'avance...
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
- en gros, ça ne sert à rien. Si vraiment on désire sécuriser des données confidentielles, mieux vaut créer soi même ses images disques sécurisées, et ne pas les laisser montées lorsque l'on en a pas besoin.
Je SNIPE la majorité de tes très intéressantes remarques pour faire court, mais chapeau pour le test, édifiant.
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Donc, déjà, ça peut coincer.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Ou bien n'ai-je pas tout compris?
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut.
Schmurtz <moi@ici.com> wrote:
- en gros, ça ne sert à rien. Si vraiment on désire sécuriser des
données confidentielles, mieux vaut créer soi même ses images disques
sécurisées, et ne pas les laisser montées lorsque l'on en a pas besoin.
Je SNIPE la majorité de tes très intéressantes remarques pour faire
court, mais chapeau pour le test, édifiant.
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité
qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui
n'aurait pas -à priori- le pass de log au départ.
Donc, déjà, ça peut coincer.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son
pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne
pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Ou bien n'ai-je pas tout compris?
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
- en gros, ça ne sert à rien. Si vraiment on désire sécuriser des données confidentielles, mieux vaut créer soi même ses images disques sécurisées, et ne pas les laisser montées lorsque l'on en a pas besoin.
Je SNIPE la majorité de tes très intéressantes remarques pour faire court, mais chapeau pour le test, édifiant.
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Donc, déjà, ça peut coincer.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Ou bien n'ai-je pas tout compris?
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut.
Patrick Stadelmann
In article <1g7i2ns.1gmc3rd1nvqs7uN%, (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login (ou le login automatique est activé, ce qui revient un peu au même), ou tu connais le "mot de passe principal" de FileVault, ou FileVault est déverouillé (ie l'utilisateur a laissé sa session ouverte)
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de l'utilisateur sur le système principal, il ne pourra pas décrypter le compte. Il lui faudra absolument le mot de passe du compte (je ne connais pas la résistance de Mac OS X au attaques visant à trouver le mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot de passe principal (ou alors, beaucoup de CPU et de temps !).
Patrick -- Patrick Stadelmann
In article <1g7i2ns.1gmc3rd1nvqs7uN%JmG@LaCase.com>,
JmG@LaCase.com (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité
qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui
n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login
(ou le login automatique est activé, ce qui revient un peu au même), ou
tu connais le "mot de passe principal" de FileVault, ou FileVault est
déverouillé (ie l'utilisateur a laissé sa session ouverte)
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son
pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne
pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de
l'utilisateur sur le système principal, il ne pourra pas décrypter le
compte. Il lui faudra absolument le mot de passe du compte (je ne
connais pas la résistance de Mac OS X au attaques visant à trouver le
mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot
de passe principal (ou alors, beaucoup de CPU et de temps !).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1g7i2ns.1gmc3rd1nvqs7uN%, (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login (ou le login automatique est activé, ce qui revient un peu au même), ou tu connais le "mot de passe principal" de FileVault, ou FileVault est déverouillé (ie l'utilisateur a laissé sa session ouverte)
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de l'utilisateur sur le système principal, il ne pourra pas décrypter le compte. Il lui faudra absolument le mot de passe du compte (je ne connais pas la résistance de Mac OS X au attaques visant à trouver le mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot de passe principal (ou alors, beaucoup de CPU et de temps !).
Patrick -- Patrick Stadelmann
Schmurtz
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
C'est vrai, je n'y avais pas pensé. Dans ce cas là, c'est utile.
-- Schmurtz
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité
qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui
n'aurait pas -à priori- le pass de log au départ.
C'est vrai, je n'y avais pas pensé. Dans ce cas là, c'est utile.
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
C'est vrai, je n'y avais pas pensé. Dans ce cas là, c'est utile.
-- Schmurtz
JmG
Patrick Stadelmann wrote:
In article <1g7i2ns.1gmc3rd1nvqs7uN%, (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login (ou le login automatique est activé, ce qui revient un peu au même), ou tu connais le "mot de passe principal" de FileVault, ou FileVault est déverouillé (ie l'utilisateur a laissé sa session ouverte)
Donc, le risque est très minime, vu que quelqu'un qui volerait un portable serait un peu obligé de le refermer pour partir avec. Comme ils ont -enfin- remis dans l'OS la possibilité de verrouiller au réveil, ça le fait très bien.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de l'utilisateur sur le système principal, il ne pourra pas décrypter le compte. Il lui faudra absolument le mot de passe du compte (je ne connais pas la résistance de Mac OS X au attaques visant à trouver le mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot de passe principal (ou alors, beaucoup de CPU et de temps !).
Oui, ok... bon... ça rassure un peu donc... merci... :)
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <1g7i2ns.1gmc3rd1nvqs7uN%JmG@LaCase.com>,
JmG@LaCase.com (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité
qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui
n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login
(ou le login automatique est activé, ce qui revient un peu au même), ou
tu connais le "mot de passe principal" de FileVault, ou FileVault est
déverouillé (ie l'utilisateur a laissé sa session ouverte)
Donc, le risque est très minime, vu que quelqu'un qui volerait un
portable serait un peu obligé de le refermer pour partir avec.
Comme ils ont -enfin- remis dans l'OS la possibilité de verrouiller au
réveil, ça le fait très bien.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son
pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne
pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de
l'utilisateur sur le système principal, il ne pourra pas décrypter le
compte. Il lui faudra absolument le mot de passe du compte (je ne
connais pas la résistance de Mac OS X au attaques visant à trouver le
mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot
de passe principal (ou alors, beaucoup de CPU et de temps !).
Oui, ok... bon... ça rassure un peu donc... merci... :)
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
In article <1g7i2ns.1gmc3rd1nvqs7uN%, (JmG) wrote:
Cela dit, j'ai lu quelque part que le FileVault n'était une sécurité qu'en cas de vol (portables essentiellement), donc, par quelqu'un qui n'aurait pas -à priori- le pass de log au départ.
Les données sont innaccessibles sauf si : tu as le mot de passe de login (ou le login automatique est activé, ce qui revient un peu au même), ou tu connais le "mot de passe principal" de FileVault, ou FileVault est déverouillé (ie l'utilisateur a laissé sa session ouverte)
Donc, le risque est très minime, vu que quelqu'un qui volerait un portable serait un peu obligé de le refermer pour partir avec. Comme ils ont -enfin- remis dans l'OS la possibilité de verrouiller au réveil, ça le fait très bien.
Mais admettons qu'il arrive à booter d'un autre volume (donc avec son pass), si FileVault est activé et que l'indélicat n'a pas le pass, il ne pourra quand même pas décrypter les données du user volé, n'est-ce pas?
Non. Même en hackant le système pour changer le mot de passe de login de l'utilisateur sur le système principal, il ne pourra pas décrypter le compte. Il lui faudra absolument le mot de passe du compte (je ne connais pas la résistance de Mac OS X au attaques visant à trouver le mot de passe d'un compte, ce qui pourrait affaiblir FileVault) ou le mot de passe principal (ou alors, beaucoup de CPU et de temps !).
Oui, ok... bon... ça rassure un peu donc... merci... :)
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut.
