Каморка

2MarkM

Ни фига там не зашифровано (из того что можно использовать), более того сертификат передаётся открытым текстом до инициализации SSL.
Ведь именно для это он и нужен

Ключ у вас один, зачем хранить его копии везде где только можно, я не понимаю.
Задача - сделать его недоступным админам, я тебе сказал как этого можно добиться.
Зачем токен хранить и юзера, я не понимаю.
Private key можно сделать неизвлекаемым, и всё.
Пускай главный админ и хранит токен у себя, и вставляет его в USB когда надо.
Токен, к тому же закрыт паролем, пароль можно дать другому человеку и т.д. и т.п.
Нафига юзверей в это дело вовлекать?

Ivan писал(а):
Только не смейся ладно...я тут все вникаю, потому что скоро мне надо будет тоже заняться безопасностью нашего проекта, а не для того чтобы тут крассоваться...

Вот такая еще идея: на маленьком CD (типа визитки) пишется ключ. На этом CD по аутозапуску запускается маленткая апликуха которая автоматом пишет этот ключ в то поле...

CD скопировать - много ума не надо!

Marmot писал(а):
CD скопировать - много ума не надо!

You can keep the key on the CD encrypted and to decrypt it ask user for a password.

Koroche...esli zahotet' mozhno vsikiye pregrady pridumat'.
Ne nado zavivat' a compromise mezhdu slochnost y stoymost nu y konezhno o tselesobrasnost'

Ivan писал(а): апликуха которая автоматом пишет этот ключ в то поле...

А как это будет работать?
Расскажи поподробнее, плс

Marmot писал(а):

Ivan писал(а): апликуха которая автоматом пишет этот ключ в то поле...

А как это будет работать?
Расскажи поподробнее, плс

For example there are a lot of programs that automatically fills up web forms. So I think it is possible. A fast approach is to copy to the clippboard and on the form using JavaScript paste from the clippboard. So I don't understand your ironicsism. JavaScript can access the clippboard, so as soon as the key is pasted into the field you can clean up the clippboard.

Ivan писал(а):

Marmot писал(а):

Ivan писал(а): апликуха которая автоматом пишет этот ключ в то поле...

А как это будет работать?
Расскажи поподробнее, плс

For example there are a lot of programs that automatically fills up web forms. So I think it is possible. A fast approach is to copy to the clippboard and on the form using JavaScript paste from the clippboard. So I don't understand your ironicsism. JavaScript can access the clippboard, so as soon as the key is pasted into the field you can clean up the clippboard.

Да я вобщем-то не иронизировал...
Только вот работа с clipboard using JavaScripta is a browser specific feature.
Не секьюрно это...
Да и юзверю хлопотно,может у него там в clipboard чего-нибудь нужное и важное лежит.
Специально же придумали PKI для этого, зачем изобретать велосипед?

MarkM писал(а):Есть 3-х слойный веб апп. Браузер -> веб апп сервер -> БД.
Юзера хотят шифровать инфу, которая лежит в БД, фамилии, номера и тп. Типа засекретить данные от админов.
Я ДБА. Мне эти данные тоже видеть не полагается.
Я предложил шифровать в БД, что прозрачно для апп, но ключ давать извне.
Вопрос.
Где (и как) хранить ключ шифрования?
В БД я хранить не хочу, т.к. я им потенциально могу воспользоваться.
Хранить в Апп, веб-сервере - сисадмины могут докопаться.
Выход - раз ключ нужен юзерам - хранить у них на тонком клиенте.

Как?

никак. нужен encryption-aware клиент - на jave, в форме activex или скажем в форме http proxy. на пустом броузере сделать не получится.

как вариант можете поставить encryption прокси перед существующим сервером. этот бокс должен стоять в lock down environment, генерить и хранить per-client keys (которые вы конечно же не забудете rotate from time to time), принимать ssl'ed connections from the client, relay'ить данные между клиентами и сервером, на лету (transparently) шифруя / дешифруя sensitive информацию от/к клиентy. для пущей секюрности можете воткнуть в прокси криптожелезку, чтобы хранить на ней клиентские ключи. piece of cake

[trl]Kakoj takoj proksi?
Eto special'naja softina? Ona prodajetsja? Ili nado special'no pisat'?
Kin' link plizzz[/trl]

MarkM писал(а):[trl]Kakoj takoj proksi?
Eto special'naja softina? Ona prodajetsja? Ili nado special'no pisat'?
Kin' link plizzz[/trl]

здрасте прокси - да, это, software component that accepts clients connections on behalf of the server, then establishes its own connection to the target server and relays data back and forth between two sides potentially mangling this data in transition. client <--> proxy <--> server

обычно proxy стоят ближе к клиенту, чем к серверу и занимаются разного рода кэшированием и access control'ом (то есть кто куда может ходить "наружу"). типичный пример - http proxy (см гугл)

прокси также бывают обычные и transparent. пример второго - squid http proxy (или какой-то его вариант, см опять же гугл)

в вашем случае - надо специально писать, особенно если вы не хотите иметь response lag и соответсвенно будете делать on-the-fly stream (as opposed to buffered) encryption.

drain bamage писал(а):

MarkM писал(а):[trl]Kakoj takoj proksi?
Eto special'naja softina? Ona prodajetsja? Ili nado special'no pisat'?
Kin' link plizzz[/trl]

здрасте прокси - да, это, software component that accepts clients connections on behalf of the server, then establishes its own connection to the target server and relays data back and forth between two sides potentially mangling this data in transition. client <--> proxy <--> server

обычно proxy стоят ближе к клиенту, чем к серверу и занимаются разного рода кэшированием и access control'ом (то есть кто куда может ходить "наружу"). типичный пример - http proxy (см гугл)

прокси также бывают обычные и transparent. пример второго - squid http proxy (или какой-то его вариант, см опять же гугл)

в вашем случае - надо специально писать, особенно если вы не хотите иметь response lag и соответсвенно будете делать on-the-fly stream (as opposed to buffered) encryption.

Ну ты посоветовал, ты хочешь сказать что они должны парсить HTML stream посылаемый с appservera и декриптить данные?
По-моему ты не понял их проблемы.

[trn]Gospoda, gospoda,

povtorjaju.
nado kak to hranit' i peredavat' kljuch dlja shifrovanija dannyh v bazu dannyh, cheres app server.
BD i AS stojat na nashej territorri. Tonkie klienty na territorrii zakazchika.
Ideja s proksi horoshaja. Ego mozhno postavit' na territorrii zakazchika i hranit' kljuch na nem.

Ja predstavljau chto takoe Skvid.
No ja ne znaju, kak ego zastavit' peredat' kljuch.
Esli nel'zja? Pisat' svoj proksi?

[/trn]

MarkM писал(а):[trn]Ja predstavljau chto takoe Skvid.
No ja ne znaju, kak ego zastavit' peredat' kljuch.
Esli nel'zja? Pisat' svoj proksi?

[/trn]

drain bamage предложил использовать прокси для криптования, а не для передачи ключа, потому как проблему чтения ключа с клиента он не решает!

Если так уж нужно иметь ключ на каждом клиенте, то можно хранить его в зашифрованном виде как certificate extention.
Сертификат можно поставить на browser напрямую или используя PKI токены.
Appserver может извлечь и расшифровать ключ из сертификата и передать его в DB.

Добавление:

Оопс, а вот это я и не заметил:

MarkM писал(а):Его можно поставить на территоррии заказчика и хранить ключ на нем.

Ключ можно добавить как дополнительный header к реквесту
Только, блин, некрасиво это как-то.

Тут сидел на митинге, скучал, и пришло мне в голову, что если к юзерам можно ящик поставить то можно сделать так:
1.Ставим к юзерм ящик с апачем
2.В апач кладём javascript file с ключом
3.Из старнички вызываем этот файл и получаем наш ключ

Теперь можно и на сервер его послать, а ещё лучше шифровать всё прямо на страничке в момент submita.
Я где-то видел DES на Javascripte.
Тогда ключ и нешифрованные данные никогда не будут выходить за пределы локалки.

Marmot писал(а):
Ну ты посоветовал, ты хочешь сказать что они должны парсить HTML stream посылаемый с appservera и декриптить данные?
По-моему ты не понял их проблемы.

мармот, это ты не понял их проблемы. прочитай условие задачи еще раз ни в бд, ни на аппсервере plaintext'a быть не должно. plaintext должен шифроваться где-то между аппсервером и клиентским браузером. ясный пень, что в/на чистом браузере хранить можно только certified asymmetric key (и то с боольшими оговорками), который столь же очевидным образом проблемы не решает, поскольку не может быть использован для шифрации <b>html</b> content'a. hense the вывод - нужен еще один hop ... который для простоты обозначения назовем модным словом proxy see my point так сказать ?

MarkM писал(а):[trn]Gospoda, gospoda,

povtorjaju.
nado kak to hranit' i peredavat' kljuch dlja shifrovanija dannyh v bazu dannyh, cheres app server.
BD i AS stojat na nashej territorri. Tonkie klienty na territorrii zakazchika.
Ideja s proksi horoshaja.[/trn][trn] Ego mozhno postavit' na territorrii zakazchika i hranit' kljuch na nem.[/trn]

если ты сам еще не понял - это очень грамотная со всех сторон (включая маркетинговую) идея.