Учет умер, да здравствует учет!

31.03.21

Разработка - Математика и алгоритмы

Все громче звучат в последнее время разговоры о том, что профессия бухгалтера (как, впрочем, и еще целый ряд других) не выдерживает напора современных технологий. Даже если и есть тут некоторое преувеличение, то не такое уж и большое. Откройте прямо сейчас hh. Профессия «бухгалтер». В Москве 7 тысяч вакансий на полмиллиона соискателей. При том, что вакансий «программист» чуть ли не в три раза больше (20 тысяч). И пусть счет все еще идет на тысячи, не стоит обольщаться. Это — всего лишь инерция. Скоро все закончится, потому что… учет умер.

Учет, как особый, достаточно сложный и уважаемый вид человеческой деятельности действительно умер. Навсегда ушли те времена, когда человек, нашедший в себе силы освоить премудрости дебета и кредита, сразу становился обладателем магических перков. Он мог разговаривать с налоговой и следить за тем, чтобы не разворовали склад. При том, что не стоял день и ночь рядом со складом с ружьем, а использовал магию цифр, сидя в комфортном кабинете. Теперь с налоговой разговаривает программа 1С. И о чем они там перешептываются, похоже, скоро уже не будет знать никто. А на страже склада стоит чудесный алгоритм под названием «контроль отрицательных остатков» (плохо, правда, стоит, но это тема отдельного разговора). Человеку же остается всего лишь незавидная роль оператора по вводу данных. Да и то, пока. Совсем скоро программы окончательно научатся обмениваться данными без участия людей-операторов, и будет у нас самый настоящий и повсеместный «скайнет».

Нельзя сказать, что такого рода разговоры совсем оторваны от реальности, но в основе их все-таки лежит невежество. Технологии не портят жизнь людям. Да, они ее меняют. И, да, заставляют учиться новому. Но эта новая жизнь безусловно лучше старой. Технологии не ограничивают людей, а напротив, дают им новые, доселе невиданные возможности и способности. И я хочу показать это на одном, конкретном примере, связанном с учетом.

Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.

Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет, чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.

Допустим, все только начинается. Прошли несколько операций на складе. У человека есть несколько первичных документов, а в базе есть соответствующие им записи. Человек сверяет каждый документ с данными в базе и попутно проделывает следующее (чтобы текст был понятен непрограммистам, я воспользуюсь неким псевдоязыком программирования):

 

для каждого документа из документов в базе
  превратим данные документа в строку
  добавим к ней предыдущий ключ/хеш
  получим новый ключ/хеш для этой составной строки
  запишем в журнал ссылку на документ и новый ключ
конец


В этих шести строчках описана технология блокчейн в чистом виде. Под получением ключа/хеша подразумевается вычисление какой-либо хеш-функции, например SHA256. Сразу надо отметить, что человек может вести журнал в той же самой базе. Как мы уже говорили, данные в базе могут изменить. В том числе могут изменить сам журнал. Но человека это не волнует. Потому что, как вы увидите дальше, изменить журнал незаметно для человека не получится.

Вернемся к процессу. Первая порция документов сверена и занесена в журнал. Далее происходит самое важное действие. Человек переписывает последний ключ в какое-нибудь секретное место (например на бумагу, это будет самый надежный вариант; если использовать SHA256, это займет не более 2 минут, я проверял). Теперь сеанс сверки можно считать завершенным.

Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы.

Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:

 

для каждой записи из журнала
  получим данные документа по ссылке и превратим их в строку
  добавим к ней значение ключа из предыдущей записи
  получим значение ключа для этой составной строки
  сравним его с ключом, который записан в журнале
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
  превратим данные документа в строку
  добавим к ней предыдущий ключ
  получим новый ключ для этой составной строки
  запишем в журнал ссылку на документ и новый ключ
конец


Мы убедились, что документы, внесенные в журнал, не изменялись. После чего добавили в журнал новую порцию документов, попутно сверяя каждый с первичным документом. Теперь осталось определиться с тем, что делать, когда обнаруживается изменение ранее введенного в систему документа. В принципе, это нормальный рабочий момент. Время от времени он имеет место быть. Поэтому, человек принимает следующее решение. При обнаружении изменения, делать повторную сверку с первичным документом, старую запись в журнале оставлять как есть, а в конец журнала добавлять новую запись. В старой записи указывать ссылку на новую, как на потомка. А в новой указывать ссылку на старую, как на предка. И, наконец, использовать указатель на предка при формировании ключа. Список действий в окончательном виде выглядит так:

для каждой записи из журнала
  если запись не имеет потомка
    получим данные документа по ссылке и превратим их в строку
    добавим к ней значение ключа из предыдущей записи
    добавим значение указателя на предка
    получим значение ключа для этой составной строки
    если вычисленный ключ не равен ключу в журнале
      запишем в журнал новую запись с указанием предка
      в старой записи дадим указание на потомка
    конец
  конец
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
  превратим данные документа в строку
  добавим к ней предыдущий ключ
  получим новый ключ для этой составной строки
  запишем в журнал ссылку на документ и новый ключ
конец


Разумеется, все это делается не в ручном режиме. Все действия, за исключением собственно сверки с первичными документами, выполняются программой, которая запускается при каждом сеансе контроля. Описанная здесь система представляет собой абсолютное "всевидящее око". Любое добавление или изменение будет обнаружено с помощью журнала. После чего правомерность операции может быть подтверждена путем сверки с первичным документом. В свою очередь сам журнал защищен от подмены технологией блокчейн и записью последнего ключа в секретное место.

Единственная теоретически возможная атака заключается в подмене программы. Действительно, есть такая максима, гласящая, что абсолютно доверять можно только той программе, которую написал сам. На самом деле, ее следовало бы перефразировать так: абсолютно доверять можно только той программе, которую ты прочитал сам непосредственно перед запуском. Представленная здесь программа настолько проста, что вполне удовлетворяет этому условию. В этих 19 строках просто негде спрятать закладку.

Поэтому программу можно контролировать визуально. Впрочем, существуют еще и достаточно надежные способы контроля, основанные также на вычислении хеш-функции и сравнении результатов.

Используя эту, в общем не хитрую технологию, человек получает способность контролировать любые объемы данных. Причем, результат будет эквивалентен тому, который получился бы при сверке абсолютно всех документов в каждом сеансе контроля. Это дает возможность создавать абсолютно надежные системы контроля. В свою очередь, от человека требуется совсем не много. Всего лишь освоить тот или иной способ контроля над запускаемыми программами.

На этом простом примере я хотел показать, что технологии могут и должны быть гуманными. Не ограничивать человека, а напротив, открывать ему новые горизонты. Конечно, контроль данных - тема хотя и важная, но это далеко не все, что есть в учете. Я уверен, будут (или даже уже есть) и другие технологии, расширяющие возможности человека в области учета. Учет, как институт защиты интересов участников бизнеса, конечно же не умер. Просто он становится другим. Лучше и надежнее. При этом роль человека не уменьшается, а наоборот, по мере того, как растут возможности человека, растет и его роль в процессе.

блокчейн

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1754    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4416    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    7458    4    SpaceOfMyHead    17    

56

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    7855    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4444    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8835    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

Подробный разбор, с примером использования, встроенного механизма кластеризации 1С.

31.08.2021    7801    dusha0020    8    

70
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Torin 741 31.03.21 17:28 Сейчас в теме
(0)
Профессия «бухгалтер». В Москве 7 тысяч вакансий на полмиллиона соискателей."

как говорил мой препод на кафедре! "экономистов/финансистов/бухгалтеров - много! Специалистов - нету"

Очень часто сталкиваешься с тенденцией что программист - технолог ( он обязан все знать о технологии производства), программист - конструктор ( он обязан знать конструкцию детали от и до по ЕСКД) , программист - главный механик ( он должен знать все о станках и оборудовании) , и так далее! Почему, как - это возникло в умах? - загадка! вот и термин "тыжпрограммист"

Представим себе человека и некоторую учетную систему.
- на бумажном носителе. И что делает человек? он используя методы проверки +-/* считает все "на косточках" ! :)

P|S Лучшая система автоматизации рабочего времени - тетрис! Процесс есть , результат есть , но кому он нужен? :)
2. t278 56 01.04.21 02:15 Сейчас в теме
(1) потому что там программа, ну а ты должен знать как она работает. Досконально.
3. mkalimulin 1148 01.04.21 09:18 Сейчас в теме
(2) Это не так уж сложно. Всего лишь 19 строчек. Почти как "отче наш". А его каждый крестьянин знал наизусть
31. Indgo 338 14.04.21 11:55 Сейчас в теме
(3) Мишаня говорил я тебе еще 2 года назад - купи BTC и брось ты это дело.
32. mkalimulin 1148 14.04.21 13:24 Сейчас в теме
(31) Нехорошо это. Дело бросать ))
4. Chelper 7 01.04.21 10:23 Сейчас в теме
Разбирался в технологии "блокчейн" ещё в 2018 году.
Отлично работает для нематериальных активов.
Отлично поможет в сверке информации между информацией из первичных документов и информацией, содержащейся в базе данных.
Никак не помогает в проверке материальных ценностей.
В первичном документе количество 100 000.
В базе данных количество соотвествует - 100 000.
В блокчейне зафиксировали 100 000.
Привезли 99 000 на склад юр лица.
Привезли 1 000 домой кладовщику.
Кладовщик подписал первичный документ.
Всё правильно отразил в базе.
В конце месяца 1 000 списали на нормативные производственные потери.
Блокчейн сходится, кладовщик рад, поделился с начальником производства у которого тоже в блокчейне всё правильно.

Эти проблемы будут решаться робототехникой, где погрешность останется но будет очень незначительной.
7. mkalimulin 1148 01.04.21 11:42 Сейчас в теме
(4) Так надо фиксировать не до, а после
28. DatiniFM 04.04.21 10:04 Сейчас в теме
(4) Это уже решается в НАСТОЯЩИХ автоматизированных системах производства. Например уже есть у меня бетонный завод итальянской технлогии - все что залили в закрытый реактор и что получили - автоматически учитывается факт. Также есть раскройная линия рулонных матераилов для обуви (есть и для швейной продукции)- запускаются рулоны и получаются крой - все абсолютно точно сколько потратили и получили - человек не вмешается т как на уровне микропроцессоров учет.
29. mkalimulin 1148 04.04.21 10:34 Сейчас в теме
(28) Это все хорошо. Но вы ведь рулонные материалы не из любви к искусству производите. Вы их, как я догадываюсь, потом продаете. И вот здесь некто возьмет и поменяет 101х110 на 110х101. Что вы будете делать?
30. mkalimulin 1148 05.04.21 10:41 Сейчас в теме
(28) И, кстати, ваша НАСТОЯЩАЯ автоматизированная система вместе с вашей верой в микропроцессоры - это идеальная среда для злоумышленника. Вы верите в свою систему и не проверяете ее (или проверяете редко). Злоумышленник залезет в нее и будет кроить понемногу в свою пользу, а вы будете пребывать в полной уверенности, что у вас все хорошо
5. booksfill 01.04.21 10:46 Сейчас в теме
Хорошая статья.

Жаль, что возникает множество вопросов и по алгоритмам получения тех самых строк и по хранению конечного ключа и т.п.
В другой статье, того же автора, большинство трудностей профессионально разложено "по полочкам".

Я это к тому, что хотелось бы пример, не завязанный на какую-то библиотеку, расширение (нет смысла разбираться в мегатоннах кода, направленных на решение множества задач), как это реально было использовано в 1С.
Одно дело прочитать (здесь же, в другой статье) идею, что таким образом можно обеспечить сверку взаиморасчетов, и совсем другое глянуть на реализацию. Тогда можно было бы поиграться с примером, оценить все недоговоренные нюансы, и понять насколько это применимо.
8. mkalimulin 1148 01.04.21 11:45 Сейчас в теме
(5) Спасибо. Я хотел, чтобы статья была понятна непрограммистам. Статью с примерами кода на 1С вы можете найти здесь https://infostart.ru/public/728995/
6. Dragonim 139 01.04.21 11:06 Сейчас в теме
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки.


Можно закрыть период, а потом провести сверку.

А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет, чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности.


А как человек может обойти правильно настроенные права доступа? А система логирования не посылает письма при аномальной активности?

И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов.


Например: 1. сверка документов в закрытом периоде 2. ограничение доступа 3. логирование с отчетом об аномальной активности. Это всё вы написали раньше. Я даже ни чего не придумывал.

Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.


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

Дальше, опираясь на этот параграф, автор доказывает, что только блокчейн спасёт мир. Только с помощью блокчейна можно быть уверенным, что никто ни чего не изменил и собственник предприятия должен каждый раз сам всё сверять, а потом переписывать итоговый SHA256 в свой блокнотик, потому что только так может поступать нормальный параноик.

Разумеется связь реального мира с учетом автор опускает, потому что это само собой разумеется, в реальном мире все хорошо, проблема только в возможности незаметно поменять документы в учетной системе.
9. mkalimulin 1148 01.04.21 11:51 Сейчас в теме
(6) золотые слова:
"...прошивал документы и ведомости, после чего отдавал их на ответственное хранение в архив под роспись"
именно это и возрождает блокчейн на новом технологическом уровне.
Без блокчейна у вас есть база, в которой ничего не прошито и не скреплено. И все можно менять на основе школьного курса информатики и пары часов общения с гуглом
10. Dragonim 139 01.04.21 12:01 Сейчас в теме
(9) Кто-то отменил закрытие периода?
11. mkalimulin 1148 01.04.21 12:07 Сейчас в теме
(10) Кто-то отменил UPDATE ... WHERE ... ?
12. Dragonim 139 01.04.21 12:37 Сейчас в теме
(11) т.е. у вы боитесь что кто-то напрямую обратиться к базе данных и поменяет документ в учете? Я хочу вас огорчить, у вас проблема не с учетом, у вас проблема с безопасностью и блокчейн тут точно не поможет.
13. mkalimulin 1148 01.04.21 12:40 Сейчас в теме
(12) Проблема с безопасностью есть всегда и у всех. Просто некоторые сумели убедить себя, что они умнее всех и их систему никто и никогда не обойдет.
Блокчейн как раз решает проблему абсолютно надежно, потому что заходит с другой стороны
Gulloper; +1 Ответить
14. Dragonim 139 01.04.21 12:45 Сейчас в теме
(13)
Блокчейн как раз решает проблему абсолютно надежно, потому что заходит с другой стороны


Какой другой стороны? У вас проблема с безопасностью. Имеется человек который может работать напрямую с базой данных. При желании он может отслеживать создание новых записей в базу данных ещё на этапе транзакций и менять их по своему усмотрению. У вас в блокчейн сразу будут писаться неверные записи, где бы этот блокчейн не находился. Хоть запроверяйтесь,
18. mkalimulin 1148 01.04.21 12:57 Сейчас в теме
(14) Если подменять записи в блокчейне, то и последний ключ будет другой. Но в любом случае спасибо за ценное замечание. Я действительно забыл акцентировать внимание на то, что последний ключ берется из оперативной памяти
15. Dragonim 139 01.04.21 12:50 Сейчас в теме
(13) Супер идея, ловите. Если у вас есть доступ к базе данных 1С напрямую, то вы можете из неё вытащить пароль администратора и скачать конфигурацию. Меняем конфигурацию таким образом чтобы для интересующего нас документа создавался двойник. Первый документ в двойнике это документ отображаемый при открытии документа для просмотра, а второй документ это тот который изменён нужным образом и проведён, по нему же считается контрольная сумма.

В такой супер схеме даже нельзя будет найти концов. Вот главный бухгалтер открыл документ в 1С посмотреть что там записано, открыжил его и сказал что всё хорошо, а на самом деле в учет и блокчейн ушёл совсем другой документ.
16. mkalimulin 1148 01.04.21 12:54 Сейчас в теме
(15) Подмену конфигурации не сложно обнаружить
17. Dragonim 139 01.04.21 12:56 Сейчас в теме
19. mkalimulin 1148 01.04.21 12:58 Сейчас в теме
(17) Через контрольный ключ. Вы никогда не обращали внимание на то, что сейчас многие стараются сопровождать свои программы контрольным ключом?
20. Dragonim 139 01.04.21 13:04 Сейчас в теме
(19) Ну тогда и документов при первой записи можно создавать "контрольный ключ" (что бы это не было) и записывать этот ключ в отдельную базу данных и ни какого блокчейна не надо.

А если вдруг, чисто случайно, поинтересоваться что такое ЭЦП и как с помощью неё можно подписывать электронные документы любого вида, то вообще благодать настанет. Можно без блокчейна подписывать документы при проверки и никто их поменять не сможет, а если поменяет то это сразу будет заметно.
21. mkalimulin 1148 01.04.21 13:10 Сейчас в теме
(20) Я может быть чего-то не понимаю. Если не прав, поправьте. Но с ЭЦП вам придется как-то решать вопрос сохранности ключа. Т.е. ключ должен хранится на отдельном устройстве. И в идеале это устройство связывается с основной базой только через посредника-человека. Человек руками вбивает данные документа на защищенном устройстве. Получает подпись. Затем опять руками вбивает подпись в основной базе. Есть какие-то другие безопасные способы подписания документа?
22. Dragonim 139 01.04.21 13:21 Сейчас в теме
(21) Ключ храниться на специальных устройствах, обычно это спец. флешка USB, пользователь вставляет такую флешку, вводит пароль, на его устройстве (не на сервере или в базе данных) подписываются данные и отправляются на сервер 1С. На стороне сервера 1С проверяется пришедшая подпись, если она соответствует пользователю который авторизовался в базу, то 1С записывает данные в базу данных. Если подпись не соответствует, то происходит отказ записи.

Если вы боитесь за мифический "UPDATE ... WHERE ...", то можно для отправляемых данных создавать sha256, подписывать его и после записи в базу данных проверять, что данные соответствуют подписанному sha256.
23. mkalimulin 1148 01.04.21 13:27 Сейчас в теме
(22) При этом ключ с флешки попадает на ваше устройство, а с вашего устройства может уйти и на сервер. Или как?
24. Dragonim 139 01.04.21 13:36 Сейчас в теме
(23)
(22) При этом ключ с флешки попадает на ваше устройство, а с вашего устройства может уйти и на сервер. Или как?


Если разговор идёт о спец. устройстве, а не о кустарном производстве, то ключ считать нельзя, можно им только подписать.

Вот немного информации https://cryptopro.ru/products/fkc/info
25. mkalimulin 1148 01.04.21 13:43 Сейчас в теме
(24) Спасибо. Прочитал и вот что понял. Раньше была безопасная технология хранения ключей на флешках. Ну как безопасная. Просто все думали, что безопасная. А потом оказалось, что (цитирую)
"... данные стандарты были разработаны достаточно давно и не учитывают возникновение новых угроз, таких как уязвимость к атакам подмены подписи или хэш-значения в канале связи между микропроцессором карты (ключа) и программным обеспечением на компьютере."
И теперь придумали новую технологию. Которую будут считать безопасной до тех пор, пока...
Эта песня будет вечной!
А вот блокчейн решает проблему с другого конца и решает ее абсолютно надежно
Gulloper; +1 Ответить
26. konovalovrg 01.04.21 19:02 Сейчас в теме
Отличная статья, неожиданно на 1С, которую все не-1С-ники ненавидят ))
У нас (платежный сервис Joys) все на блокчейне и есть модуль для 1С (Рарус писал нам его) для покупки товаров в магазинах через моментальную конвертацию монет в рубль.
А.. кстати оно же работает и как СБП, в том числе.
27. mkalimulin 1148 01.04.21 20:08 Сейчас в теме
(26) Спасибо! Приятно слышать такое среди моря голосов: фигня какая-то! излишне! громоздко! не нужно! и т.д.
Оставьте свое сообщение