2011-01-04 1 views
2

Это мой первый вопрос, поэтому дайте мне знать, если я делаю что-то неправильно!Является ли мой метод обеспечения целостности строки безопасным?

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

Эта награда содержится в специально отформатированной строке, эта строка МОЖЕТ быть подделана людьми, которые намерены обмануть систему. Это не огромная проблема, но я сделал некоторые шаги, чтобы предотвратить ее, теперь мой вопрос ... Насколько безопасны эти шаги?

Вот два примера строк:

***Code-v1.0:31c8f90a4050:1001:0:C:1337 
***Code-v1.0:6a9c4e8d92da:1002:C4D23A1B:C:1337 

Струны отформатированные как так:

***Code-v1.0:HASH:CODE_ID:REDEEM_ONCE:CODE_ACTION:ARG 
(REDEEM_ONCE has 3 possible values) 

Моя хеширования система работает следующим образом:

salt = "************:***"; // didnt think it wise to post this, but the length is 
          // the same and its alphanumeric 
MD5 = salt . ":" . codeParts[2] . codeParts[5] . codeParts[4] . ":" . codeParts[3] . ":"; 
MD5 .= codeParts[4] . codeParts[3] . ":" . codeParts[5] . codeParts[2]; 

Является ли это безопасный способ сделать это, код не может быть изменен без влияния на хеш, но, безусловно, хеши могут содержать коли де, и если кто-то разработал схему хэширования, все становится бессмысленным (это немного меньше риска просто «найти» его, как на стороне сервера, но если кто-то это выяснит).

Что вы думаете?

+0

Если MD5 кажется небезопасным, вы можете использовать SHA-256 или SHA-512. – fiction

+0

Будет ли это легитимно повышать безопасность этого, или это будет едва ли разница? – R4000

ответ

1

Если вы отправили детали и хэш, но НЕ соль в любом месте (просто чтобы убедиться;)), вы выглядите так, будто находитесь на правильном пути. Некоторые замечания:

  1. Почему вы используете md5? Семейство SHA более безопасно.
  2. Нашего провайдер оплаты недавно пошел форматирование строк, как это, чтобы обеспечить более длинные строки, в которых столкновение (их рассуждение) являются менее вероятным:

codepart1.SALT.codepart2.SALT.codepart3.SALT и т.д.

Технически это не было бы солью я думаю, но все же ..

Так отправить хэш и ваш codeparts и воссоздать хэш от codeparts и солей/secretstring и вы установлены.

Я вижу одну проблему: ваша секретная строка должна быть действительно секретной, и она находится в вашем приложении. Таким образом, обратное проектирование может показать, как создается ваш хэш, и поэтому они могут изменять поля И хэш, который вы отправляете?

+0

Мое приложение сканирует штрих-код (и хэш), а затем отправляет его на сервер, который выполняет всю проверку, и приложение не содержит ни схемы хэширования, ни солей. Я могу принять ваш совет относительно SHA и нескольких солей. Самый большой вопрос, который я оставил сейчас, касается «повторения» одних и тех же данных в моей строке «string to hash». Это действительно повышает безопасность хэша или нет? – R4000

+0

Не должно/не имеет значения. Небольшое изменение в строке, которую вы хотите использовать, делает результат совершенно другим, даже если вы добавите 1 символ в конце. – Nanne

+0

Спасибо за помощь Нанне. +1 Принятый ответ: D – R4000