Je prépare un travail sur la "sécurité" sur Internet.
Et j'aimerai connaitre les points forts du paiement sécurisé sur
Internet et ses points faibles.
Pouvez-vous me donner quelques éléments ?
Il va falloir que l'on m'explique en quoi un chiffre calculé et codé est moins sur qu'un chiffre tiré au hasard et codé.
Justement parce qu'il existe un moyen de le calculer, non ?
De plus, je pense que la BNT est plus sur pour stocké des données chiffrées qu'un fichier de password Unix vu les conditions de saisies et d'introduction des clès.
La question n'est pas de savoir, pour autant que je comprenne, comment est stockée l'information, mais bel et bien de la génération de cette information (i.e. donnée aléatoire ou pré-calculée).
-- JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas envie de le paumer a cause d'une bevue ancillaire. BB - Une quoi ? JG - Une connerie de ta bonniche -+- Bernard Blier et Jean Gabin, le Cave se Rebiffe
Dans sa prose, Serge Ritzenthaler nous ecrivait :
Il va falloir que l'on m'explique en quoi un chiffre calculé et codé
est moins sur qu'un chiffre tiré au hasard et codé.
Justement parce qu'il existe un moyen de le calculer, non ?
De plus, je pense que la BNT est plus sur pour stocké des données
chiffrées qu'un fichier de password Unix vu les conditions de saisies
et d'introduction des clès.
La question n'est pas de savoir, pour autant que je comprenne, comment est
stockée l'information, mais bel et bien de la génération de cette
information (i.e. donnée aléatoire ou pré-calculée).
--
JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas envie
de le paumer a cause d'une bevue ancillaire.
BB - Une quoi ?
JG - Une connerie de ta bonniche
-+- Bernard Blier et Jean Gabin, le Cave se Rebiffe
Il va falloir que l'on m'explique en quoi un chiffre calculé et codé est moins sur qu'un chiffre tiré au hasard et codé.
Justement parce qu'il existe un moyen de le calculer, non ?
De plus, je pense que la BNT est plus sur pour stocké des données chiffrées qu'un fichier de password Unix vu les conditions de saisies et d'introduction des clès.
La question n'est pas de savoir, pour autant que je comprenne, comment est stockée l'information, mais bel et bien de la génération de cette information (i.e. donnée aléatoire ou pré-calculée).
-- JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas envie de le paumer a cause d'une bevue ancillaire. BB - Une quoi ? JG - Une connerie de ta bonniche -+- Bernard Blier et Jean Gabin, le Cave se Rebiffe
Serge Ritzenthaler
"Cedric Blancher" a écrit dans le message news: | Dans sa prose, Serge Ritzenthaler nous ecrivait : | > Il va falloir que l'on m'explique en quoi un chiffre calculé et codé | > est moins sur qu'un chiffre tiré au hasard et codé. | | Justement parce qu'il existe un moyen de le calculer, non ? | Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte n'est pas le résultat du calcul, mais le résultat du calcul codé.
| > De plus, je pense que la BNT est plus sur pour stocké des données | > chiffrées qu'un fichier de password Unix vu les conditions de saisies | > et d'introduction des clès. | | La question n'est pas de savoir, pour autant que je comprenne, comment est | stockée l'information, mais bel et bien de la génération de cette | information (i.e. donnée aléatoire ou pré-calculée). | Bien si quand même, car si l'information est stockée n'importe comment elle est reconstituable. Donc les banquiers font quand même très attention à la façon de stocker la chose.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte mais la clef qui permet de le calculer. Il est donc très important qu'elle soit saisie et stocké de façon à ce que personne ne la connaisse. | -- | JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas envie | de le paumer a cause d'une bevue ancillaire. | BB - Une quoi ? | JG - Une connerie de ta bonniche | -+- Bernard Blier et Jean Gabin, le Cave se Rebiffe |
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message
news: pan.2003.12.09.09.18.08.717635@cartel-securite.fr...
| Dans sa prose, Serge Ritzenthaler nous ecrivait :
| > Il va falloir que l'on m'explique en quoi un chiffre calculé et codé
| > est moins sur qu'un chiffre tiré au hasard et codé.
|
| Justement parce qu'il existe un moyen de le calculer, non ?
|
Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte n'est
pas le résultat du calcul, mais le résultat du calcul codé.
| > De plus, je pense que la BNT est plus sur pour stocké des données
| > chiffrées qu'un fichier de password Unix vu les conditions de saisies
| > et d'introduction des clès.
|
| La question n'est pas de savoir, pour autant que je comprenne, comment est
| stockée l'information, mais bel et bien de la génération de cette
| information (i.e. donnée aléatoire ou pré-calculée).
|
Bien si quand même, car si l'information est stockée n'importe comment elle
est reconstituable. Donc les banquiers font quand même très attention à la
façon de stocker la chose.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte mais la
clef qui permet de le calculer. Il est donc très important qu'elle soit
saisie et stocké de façon à ce que personne ne la connaisse.
| --
| JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas
envie
| de le paumer a cause d'une bevue ancillaire.
| BB - Une quoi ?
| JG - Une connerie de ta bonniche
| -+- Bernard Blier et Jean Gabin, le Cave se Rebiffe
|
"Cedric Blancher" a écrit dans le message news: | Dans sa prose, Serge Ritzenthaler nous ecrivait : | > Il va falloir que l'on m'explique en quoi un chiffre calculé et codé | > est moins sur qu'un chiffre tiré au hasard et codé. | | Justement parce qu'il existe un moyen de le calculer, non ? | Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte n'est pas le résultat du calcul, mais le résultat du calcul codé.
| > De plus, je pense que la BNT est plus sur pour stocké des données | > chiffrées qu'un fichier de password Unix vu les conditions de saisies | > et d'introduction des clès. | | La question n'est pas de savoir, pour autant que je comprenne, comment est | stockée l'information, mais bel et bien de la génération de cette | information (i.e. donnée aléatoire ou pré-calculée). | Bien si quand même, car si l'information est stockée n'importe comment elle est reconstituable. Donc les banquiers font quand même très attention à la façon de stocker la chose.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte mais la clef qui permet de le calculer. Il est donc très important qu'elle soit saisie et stocké de façon à ce que personne ne la connaisse. | -- | JG - Pour une fois que je tiens un artiste de la Renaissance, j'ai pas envie | de le paumer a cause d'une bevue ancillaire. | BB - Une quoi ? | JG - Une connerie de ta bonniche | -+- Bernard Blier et Jean Gabin, le Cave se Rebiffe |
Cedric Blancher
Dans sa prose, Serge Ritzenthaler nous ecrivait :
Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte n'est pas le résultat du calcul, mais le résultat du calcul codé.
Donc au final, le résultat d'un calcul qui prend en paramètres plusieurs arguments, dont un clé qu'on voudra garder secrète. Ce qui reste au finish le résultat d'un calcul du début à la fin.
Bien si quand même, car si l'information est stockée n'importe comment elle est reconstituable. Donc les banquiers font quand même très attention à la façon de stocker la chose.
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de chiffrement, ou la clé plus un aléa, il faudra le faire avec une sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore une fois, la question me me semble pas porter sur le stockage, mais sur le calcul du CVV.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte mais la clef qui permet de le calculer. Il est donc très important qu'elle soit saisie et stocké de façon à ce que personne ne la connaisse.
Ça, je crois que tout le monde l'a compris.
L'objection porte sur le fait qu'il aurait peut-être mieux valu générer des données aléatoires et les chiffrer (puisque vous tenez à votre chiffrement) plutôt que de générer des nombres au moyen d'un algorithme pour les chiffrer ensuite, de manière à rendre ces résultats moins prédictibles.
Je m'attendais à ce que vous objectiez qu'un système se servant de nombre aléatoires aurait dû disposer d'une base de données associant les numéros de CB à leur aléas pour autoriser la vérification du CVV, base qui sera difficilement sécurisable dans son ensemble, alors que le système actuel ne nécessite que la connaissance de la clé de chiffrement, plus simple à appréhender en terme de sécurité... Arguement qui, compte tenu des contraintes pratiques, est tout à fait pertinent et recevable me semble-t-il.
-- D> Moi, j'install pas d'appli, et je ne suis jamais logué. Donc jamais de su Moi je ne me logue pas, je ne boote pas, et je n'allume pas le PC. Je n'ai jamais su -+- KD in GFA : On ne pourra plus dire qu'on savait pas. -+-
Dans sa prose, Serge Ritzenthaler nous ecrivait :
Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte
n'est pas le résultat du calcul, mais le résultat du calcul codé.
Donc au final, le résultat d'un calcul qui prend en paramètres plusieurs
arguments, dont un clé qu'on voudra garder secrète. Ce qui reste au
finish le résultat d'un calcul du début à la fin.
Bien si quand même, car si l'information est stockée n'importe comment
elle est reconstituable. Donc les banquiers font quand même très
attention à la façon de stocker la chose.
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de
chiffrement, ou la clé plus un aléa, il faudra le faire avec une
sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore
une fois, la question me me semble pas porter sur le stockage, mais sur le
calcul du CVV.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte
mais la clef qui permet de le calculer. Il est donc très important
qu'elle soit saisie et stocké de façon à ce que personne ne la
connaisse.
Ça, je crois que tout le monde l'a compris.
L'objection porte sur le fait qu'il aurait peut-être mieux valu générer
des données aléatoires et les chiffrer (puisque vous tenez à votre
chiffrement) plutôt que de générer des nombres au moyen d'un algorithme
pour les chiffrer ensuite, de manière à rendre ces résultats moins
prédictibles.
Je m'attendais à ce que vous objectiez qu'un système se servant de
nombre aléatoires aurait dû disposer d'une base de données associant
les numéros de CB à leur aléas pour autoriser la vérification du CVV,
base qui sera difficilement sécurisable dans son ensemble, alors que le
système actuel ne nécessite que la connaissance de la clé de
chiffrement, plus simple à appréhender en terme de sécurité...
Arguement qui, compte tenu des contraintes pratiques, est tout à fait
pertinent et recevable me semble-t-il.
--
D> Moi, j'install pas d'appli, et je ne suis jamais logué. Donc jamais de su
Moi je ne me logue pas, je ne boote pas, et je n'allume pas le PC.
Je n'ai jamais su
-+- KD in GFA : On ne pourra plus dire qu'on savait pas. -+-
Oui si vous avez la clef. Le CVV2 que vous lisez au dos de la carte n'est pas le résultat du calcul, mais le résultat du calcul codé.
Donc au final, le résultat d'un calcul qui prend en paramètres plusieurs arguments, dont un clé qu'on voudra garder secrète. Ce qui reste au finish le résultat d'un calcul du début à la fin.
Bien si quand même, car si l'information est stockée n'importe comment elle est reconstituable. Donc les banquiers font quand même très attention à la façon de stocker la chose.
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de chiffrement, ou la clé plus un aléa, il faudra le faire avec une sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore une fois, la question me me semble pas porter sur le stockage, mais sur le calcul du CVV.
Pour résumer ce qui est stocké, ce n'est pas les CVV de chaque carte mais la clef qui permet de le calculer. Il est donc très important qu'elle soit saisie et stocké de façon à ce que personne ne la connaisse.
Ça, je crois que tout le monde l'a compris.
L'objection porte sur le fait qu'il aurait peut-être mieux valu générer des données aléatoires et les chiffrer (puisque vous tenez à votre chiffrement) plutôt que de générer des nombres au moyen d'un algorithme pour les chiffrer ensuite, de manière à rendre ces résultats moins prédictibles.
Je m'attendais à ce que vous objectiez qu'un système se servant de nombre aléatoires aurait dû disposer d'une base de données associant les numéros de CB à leur aléas pour autoriser la vérification du CVV, base qui sera difficilement sécurisable dans son ensemble, alors que le système actuel ne nécessite que la connaissance de la clé de chiffrement, plus simple à appréhender en terme de sécurité... Arguement qui, compte tenu des contraintes pratiques, est tout à fait pertinent et recevable me semble-t-il.
-- D> Moi, j'install pas d'appli, et je ne suis jamais logué. Donc jamais de su Moi je ne me logue pas, je ne boote pas, et je n'allume pas le PC. Je n'ai jamais su -+- KD in GFA : On ne pourra plus dire qu'on savait pas. -+-
Jean-Marc Desperrier
Cedric Blancher wrote:
Je m'attendais à ce que vous objectiez qu'un système se servant de nombre aléatoires aurait dû disposer d'une base de données associant les numéros de CB à leur aléas pour autoriser la vérification du CVV, base qui sera difficilement sécurisable dans son ensemble, alors que le système actuel ne nécessite que la connaissance de la clé de chiffrement, plus simple à appréhender en terme de sécurité... Arguement qui, compte tenu des contraintes pratiques, est tout à fait pertinent et recevable me semble-t-il.
Ben, voilà, tout est plus simple quand on fait les réponses soi-même à ses question :-)
Le compromis actuel n'est pas forcément le meilleur sur la sécurité global du système (si la clé centrale de chiffrement est compromise, tout s'écroule), mais est le meilleur sur la sécurité individuelle de chaque clé (cette clé centrale est protégée avec beaucoup plus d'efforts que ne le serait les éléments individuels d'une énorme base contenant des infos pour chaque carte). Finalement ce n'est pas le choix le plus défavorable pour le client.
Cedric Blancher wrote:
Je m'attendais à ce que vous objectiez qu'un système se servant de
nombre aléatoires aurait dû disposer d'une base de données associant
les numéros de CB à leur aléas pour autoriser la vérification du CVV,
base qui sera difficilement sécurisable dans son ensemble, alors que le
système actuel ne nécessite que la connaissance de la clé de
chiffrement, plus simple à appréhender en terme de sécurité...
Arguement qui, compte tenu des contraintes pratiques, est tout à fait
pertinent et recevable me semble-t-il.
Ben, voilà, tout est plus simple quand on fait les réponses soi-même à
ses question :-)
Le compromis actuel n'est pas forcément le meilleur sur la sécurité
global du système (si la clé centrale de chiffrement est compromise,
tout s'écroule), mais est le meilleur sur la sécurité individuelle de
chaque clé (cette clé centrale est protégée avec beaucoup plus d'efforts
que ne le serait les éléments individuels d'une énorme base contenant
des infos pour chaque carte). Finalement ce n'est pas le choix le plus
défavorable pour le client.
Je m'attendais à ce que vous objectiez qu'un système se servant de nombre aléatoires aurait dû disposer d'une base de données associant les numéros de CB à leur aléas pour autoriser la vérification du CVV, base qui sera difficilement sécurisable dans son ensemble, alors que le système actuel ne nécessite que la connaissance de la clé de chiffrement, plus simple à appréhender en terme de sécurité... Arguement qui, compte tenu des contraintes pratiques, est tout à fait pertinent et recevable me semble-t-il.
Ben, voilà, tout est plus simple quand on fait les réponses soi-même à ses question :-)
Le compromis actuel n'est pas forcément le meilleur sur la sécurité global du système (si la clé centrale de chiffrement est compromise, tout s'écroule), mais est le meilleur sur la sécurité individuelle de chaque clé (cette clé centrale est protégée avec beaucoup plus d'efforts que ne le serait les éléments individuels d'une énorme base contenant des infos pour chaque carte). Finalement ce n'est pas le choix le plus défavorable pour le client.
*core*lenoir
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher wrote:
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de chiffrement, ou la clé plus un aléa, il faudra le faire avec une sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore une fois, la question me me semble pas porter sur le stockage, mais sur le calcul du CVV.
Je ne comprends pas. A quoi cela sert-il de crypter quelque chose qui, de toute manière, est imprimé en clair sur la carte ?
Dès la toute première fois ou ce numéro CVV a été transmis à n'importe quel vendeur on peut considérer que ce numéro est devenu "quasi" public puisqu'alors le dit vendeur est lui-même en possession des trois éléments: numéro de carte - date expiration - CVV.
A partir de ce moment si le dit vendeur stocke ces informations d'une manière non sécurisée ou, pire, est lui-même malhonnète, on peut considérer que ces informations peuvent être dispersées.
En matière de sécurité d'achat à distance sur des sites internet, j'estime que la méthode inventée par Visa de numéro unique de carte virtuelle est beaucoup plus sure. En effet le dit numéro de peut jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et unique fois) il devient inutilisable. Un nouveau numéro doit alors être généré pour chaque nouvelle transaction ultérieure.
Mais , bien sur, j'ai peut être mal compris l'intérêt du CVV et je ne demande pas mieux que d'avoir une explication.
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher
<blancher@cartel-securite.fr> wrote:
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de
chiffrement, ou la clé plus un aléa, il faudra le faire avec une
sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore
une fois, la question me me semble pas porter sur le stockage, mais sur le
calcul du CVV.
Je ne comprends pas. A quoi cela sert-il de crypter quelque chose
qui, de toute manière, est imprimé en clair sur la carte ?
Dès la toute première fois ou ce numéro CVV a été transmis à
n'importe quel vendeur on peut considérer que ce numéro est devenu
"quasi" public puisqu'alors le dit vendeur est lui-même en possession
des trois éléments: numéro de carte - date expiration - CVV.
A partir de ce moment si le dit vendeur stocke ces informations
d'une manière non sécurisée ou, pire, est lui-même malhonnète, on peut
considérer que ces informations peuvent être dispersées.
En matière de sécurité d'achat à distance sur des sites internet,
j'estime que la méthode inventée par Visa de numéro unique de carte
virtuelle est beaucoup plus sure. En effet le dit numéro de peut
jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et
unique fois) il devient inutilisable. Un nouveau numéro doit alors
être généré pour chaque nouvelle transaction ultérieure.
Mais , bien sur, j'ai peut être mal compris l'intérêt du CVV et je
ne demande pas mieux que d'avoir une explication.
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher wrote:
Oui. Mais ça vaut pour la clé aussi. Que vous stockiez la clé de chiffrement, ou la clé plus un aléa, il faudra le faire avec une sécurité comparable. C'est me semble-t-il évident, et pourquoi, encore une fois, la question me me semble pas porter sur le stockage, mais sur le calcul du CVV.
Je ne comprends pas. A quoi cela sert-il de crypter quelque chose qui, de toute manière, est imprimé en clair sur la carte ?
Dès la toute première fois ou ce numéro CVV a été transmis à n'importe quel vendeur on peut considérer que ce numéro est devenu "quasi" public puisqu'alors le dit vendeur est lui-même en possession des trois éléments: numéro de carte - date expiration - CVV.
A partir de ce moment si le dit vendeur stocke ces informations d'une manière non sécurisée ou, pire, est lui-même malhonnète, on peut considérer que ces informations peuvent être dispersées.
En matière de sécurité d'achat à distance sur des sites internet, j'estime que la méthode inventée par Visa de numéro unique de carte virtuelle est beaucoup plus sure. En effet le dit numéro de peut jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et unique fois) il devient inutilisable. Un nouveau numéro doit alors être généré pour chaque nouvelle transaction ultérieure.
Mais , bien sur, j'ai peut être mal compris l'intérêt du CVV et je ne demande pas mieux que d'avoir une explication.
Eric Razny
"Richard" <*core* a écrit dans le message de news:
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher wrote:
En matière de sécurité d'achat à distance sur des sites internet, j'estime que la méthode inventée par Visa de numéro unique de carte virtuelle est beaucoup plus sure. En effet le dit numéro de peut jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et unique fois) il devient inutilisable. Un nouveau numéro doit alors être généré pour chaque nouvelle transaction ultérieure.
Un problème de cette méthode est que les paiments récurrents ne peuvent plus être effectués. Ceci dit la CB n'avait pas été conçue pour ça et le carte virtuelle semble[1] effectivement plus sure. Néanmoins comme le coût pour les banques est marginal (et largement remboursé par la fraude évitée?) pourquoi payer en plus pour ça?
Du coup je reste à la méthode de paiment CB classique et en cas de pépin je fais jouer les garanties (et j'évite malgré tout les sites qui ne m'inspirent pas... ).
Eric.
[1] il faudrait que je regarde plus attentivement comment c'est généré. Car si on accède trop facilement au générateur il risque d'y avoir des cours-jus :)
"Richard" <*core*lenoir@nsa.org> a écrit dans le message de
news:3fd7d81a.1410088@news.skynet.be...
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher
<blancher@cartel-securite.fr> wrote:
En matière de sécurité d'achat à distance sur des sites internet,
j'estime que la méthode inventée par Visa de numéro unique de carte
virtuelle est beaucoup plus sure. En effet le dit numéro de peut
jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et
unique fois) il devient inutilisable. Un nouveau numéro doit alors
être généré pour chaque nouvelle transaction ultérieure.
Un problème de cette méthode est que les paiments récurrents ne peuvent plus
être effectués.
Ceci dit la CB n'avait pas été conçue pour ça et le carte virtuelle
semble[1] effectivement plus sure.
Néanmoins comme le coût pour les banques est marginal (et largement
remboursé par la fraude évitée?) pourquoi payer en plus pour ça?
Du coup je reste à la méthode de paiment CB classique et en cas de pépin je
fais jouer les garanties (et j'évite malgré tout les sites qui ne
m'inspirent pas... ).
Eric.
[1] il faudrait que je regarde plus attentivement comment c'est généré. Car
si on accède trop facilement au générateur il risque d'y avoir des cours-jus
:)
"Richard" <*core* a écrit dans le message de news:
On Tue, 09 Dec 2003 13:43:40 +0100, Cedric Blancher wrote:
En matière de sécurité d'achat à distance sur des sites internet, j'estime que la méthode inventée par Visa de numéro unique de carte virtuelle est beaucoup plus sure. En effet le dit numéro de peut jamais servir qu'une seule fois et dès qu'il est utilisé (une seule et unique fois) il devient inutilisable. Un nouveau numéro doit alors être généré pour chaque nouvelle transaction ultérieure.
Un problème de cette méthode est que les paiments récurrents ne peuvent plus être effectués. Ceci dit la CB n'avait pas été conçue pour ça et le carte virtuelle semble[1] effectivement plus sure. Néanmoins comme le coût pour les banques est marginal (et largement remboursé par la fraude évitée?) pourquoi payer en plus pour ça?
Du coup je reste à la méthode de paiment CB classique et en cas de pépin je fais jouer les garanties (et j'évite malgré tout les sites qui ne m'inspirent pas... ).
Eric.
[1] il faudrait que je regarde plus attentivement comment c'est généré. Car si on accède trop facilement au générateur il risque d'y avoir des cours-jus :)
