Там вродь надо репутацию нарабатывать

Тебеж 500 норм, в чем проблема

Тебеж 500 норм, в чем проблема

Да? Ну ладно. Попробую

Ещё есть frilansim.ru

какой же говносайт

пытаюсь авторизоваться через гугл — выдает 502

пытаюсь авторизоваться через гитхаб — выдает 500

через вк тоже 500

какой же говносайт

От создателей хабра

Репутация нужна

Не нужна. Начинал именно оттуда. Но не рекоммендую, слишком много ботов

А что рекомендуешь?

господа, а напомните плиз сборщик, который больше чем мавен котируется? тут упоминали, но что-то листать боюсь слишком долго будет

грэдл?

да

Вопрос. Как в андроиде нормально спрятать в коде приватный ключ или секрет? Прям чтобы дизассемблерята не нашли. Пока вариант стоит прятать int[] в 3 разных классах и а нужный момент объединять -> char []

в assets спрятай)

А что рекомендуешь?

Раньше бы апворк, но теперь комиссия как на фрилансере

апворк ненужен

опа

Или храни в классе и в прогарде напиши)

чет там простые задания довольно

а платят от 3к

На фриленсере надо при себе иметь: 1. Такси приложение 2. Шопинг апп 3. Клон инстаграма

4. работать в uber

Или храни в классе и в прогарде напиши)

Стринги в деобфускаторах и в .smali видно

4. работать в uber

Я к тому что там 90% заказов вот это вот

Вопрос. Как в андроиде нормально спрятать в коде приватный ключ или секрет? Прям чтобы дизассемблерята не нашли. Пока вариант стоит прятать int[] в 3 разных классах и а нужный момент объединять -> char []

Никак.

Недостаток архитектуры приложения

Клиент не должен иметь у себя ничего секретного

Нужно хранить на сервере по идее

В base64

Речь не о том, чтобы изменить место хранения

Клиент не должен иметь у себя ничего секретного

Ну post/put запрос хотелось бы как-то подписать :/

А о том, что нужно переделать архитектуры

Ну post/put запрос хотелось бы как-то подписать :/

Https?

Ssl

Гугли :)

Https?

Это против mitm

А если юзер сам захочет посмотреть какой json?

Вот есть приложение, делаю по его подобию

...

Что значит захочет посмотреть?

Чтобы посмотреть какие оно посылает запросы можно любой сниффер поставить, либо запустить эмуль и на компе фиктивный ssl выдать каким-то сниффером

...

Один из нас чего-то не понимает

Скорее всего, это я

https://ru.m.wikipedia.org/wiki/HTTPS

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства исертификат сервера проверен и ему доверяют.

На обоих сторонах есть открытый и закрытый ключ

Передающая сторона подписывает пакет своим секретным ключом и открытым сервера

И отправляет

Сервер делает то же самое

Таким образом, вкупе с шифрованием, подделать пакет невозможно, не подобрав простой множитель

Вот я делаю пост/пут запрос. Я передаю media_id, author_id. Сервер их получает, берет author_id, добавляет в бд записи с author_id одну внутриигровую валюту. Соответственно, чтобы нельзя было подделать реквест я его хочу подписать

Ну я скинул тебе направление

Реализаций морн

Море

Я неправильно выразился

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

Тогда никак

Серверу доверять нельзя

*клиенту

не совсем понимаю, что значит подделать реквест? т.е. реквесты сгенереные curl являются поддельными, например?

и принимать реквесты только от твоего приложения?

на GAE можно фильтровать по clientID, но что мешает просто повторить перехваченный запрос?)

Он хочет сделать так, чтобы сторонний человек не смог бы отправить данные серверу

А приложение бы смогло

точнее отсечь этих "посторонних"

в голову приходит только RSA

ERROR: S client not available

Да не. Это невозможно

Если приложение может это сделать, сможет сделать любой другой

ну хранить публичную часть rsa ключа клиента в бд....

в голову приходит только RSA

То есть в начале каждой сессии генерить ключи?

ну хранить публичную часть rsa ключа клиента в бд....

и просто повторить запрос достаточно

То есть в начале каждой сессии генерить ключи?

И почему это нельзя сделать не через приложение?

Беру и копирую часть кода из приложения

ну запрос то подделать можно - шифрованный ответ без приватной части ключа не прочесть

в этом весь смысл

ну запрос то подделать можно - шифрованный ответ без приватной части ключа не прочесть

у него запрос "добавь монетки"

ответ не важен)

Дальше подставляю в исходные данные фальшивые значения

Может через токены попробовать?

у него запрос "добавь монетки"

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

По-любому такие вещи надо делать на серверной части

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

А что мешает хакеру запросить одноразовый ключ для своих нужд?

а вообще сервер вполне может у себя проверить основания для добавления монеток. типа платил ли юзер и т.д.

а вообще сервер вполне может у себя проверить основания для добавления монеток. типа платил ли юзер и т.д.

+ Так работает всё

И это единственное правильное решение

вообще клиент всегда пишется с учетом того, что его могут скомпрометировать и подменить

вообще клиент всегда пишется с учетом того, что его могут скомпрометировать и подменить

+++

Я тут со слюнами у рта пытаюсь это сказать :)

привязку к номеру телефона, touchId, слепку голоса, сетчатке глаза, локации, ip, мак адресу...

и все это одновременно

Лол

звонить и спрашивать 10 секретных вопросов, запрашивать фото локации, устройства, своего лица и подтверждать вручную каждый tcp пакет

И причем всеравно нет гарантии

А нет. Вручную может сработать

тогда и юзеров не будет и проблем с ними

Бюрократию в IT!

?

Каждый пакет вручную одобрить!